On Oct 1, 2012, at 9:40 AM, Kyle Mestery (kmestery) wrote: > On Oct 1, 2012, at 2:34 AM, Daniel P. Berrange wrote: >> On Mon, Oct 01, 2012 at 03:48:32AM +0000, Kyle Mestery (kmestery) wrote: >>> On Sep 30, 2012, at 9:44 AM, Laine Stump wrote: >>>> On 09/28/2012 03:58 PM, Kyle Mestery (kmestery) wrote: >>>>> As an example, an OpenFlow controller may have certain information about the >>>>> port, specific to this controller, which it may want to store with the port itself on the >>>>> host. This especially true if an agent exists on the host which needs to read this data, >>>>> update it, and use it to perform some tasks. It's convenient to have this data stored >>>>> as close to the port itself, which in this case is the OVS DB, and having it transferred >>>>> as part of the migration protocol is also very handy. >>>>> >>>> >>>> But how big is it, and what does it look like? (I assume it's all >>>> printable ASCII, since you're getting it as the output of a shell command) >>>> >>>> If it's *really* large, possibly it would go better as a subelement of >>>> <interface>, rather than an attribute, i.e.: >>>> >>>> <interface index='1' vporttype='openvswitch'> >>>> <portdata> >>>> blah blah blah blah >>>> </portdata> >>>> </interface> >>> >>> >>> Yes. it's all printable ASCII. I think at the largest, it's possible for it to be up to a few K (e.g. 2-4K >>> or so). So perhaps making it a subelement would be the way to go. >>> >>> As for an example, let me talk to some controller people and see if I can scrounge one up. >> >> The other reason why I want to see indicitive size is to make sure we >> don't risk hitting any limits on the size of the migration cookie. >> >> Daniel > > > For the most part, this data will be well below 4K per port. However, if a feature such as > port security is utilized, it could be a list of allowed MAC addresses for the port, which could > explode the length of the data, but still be below 4K per port. > > I've added all of Laine's comments into the patch set, I'm testing now. Once that is done, I will > reformulate the patch one more time to make "portdata" a subelement of <interface> rather than > an attribute. When I complete that, I will resubmit the patches again. > Actually, I'm going to leave this as an attribute for now, since the patches work just fine as is, unless someone has a comment about specifically refactoring. I'm resending the patches now. > Thanks, > Kyle -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list