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.
Thanks,
Kyle