[ovs-dev] [netlink v3 08/16] datapath: Change listing ports to use an iterator concept.

Jesse Gross jesse at nicira.com
Tue Jan 11 04:21:12 UTC 2011


On Mon, Jan 10, 2011 at 5:05 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Mon, Jan 10, 2011 at 04:53:19PM -0500, Jesse Gross wrote:
>> Since this is just an intermediate step, the more important question
>> is what these two interfaces will look like when we actually start
>> using Netlink.
>>
>> Is it:
>> * For the flows, we always start dumping at the beginning and report
>> everything present at a given snapshot in time.
>> * For the ports, do we do the same thing (all ports at a given point)?
>>  Or do we still have userspace specify a point to start from (and
>> quantity?)?
>
> The apparently customary way for Netlink table dumping to work is for it
> to always start at the beginning and report everything.  It can't always
> generate an atomic snapshot, however, because the socket has a receive
> buffer of limited size.  (The Netlink designers must have had some kind
> of passing thought about atomic snapshots because there is an
> NLM_F_ATOMIC in include/linux/netlink.h and a few words about it in
> netlink(7), but that's the only reference to it anywhere in the Linux
> tree.)

OK, that sounds good.  I thought that you might have wanted to carry
over the semantics of the iterator in this patch to the Netlink
implementation.  I think it should always dump the full table, as is
done in other places.

>
> This keeps coming up, so it must be something you are worried about, but
> actually I'm not sure why you are so concerned.  Can you explain?

I'm just paranoid about encoding race conditions in the protocol that
we won't be able to fix.  You're right though that ultimately there
will be a buffer size limit that it is theoretically possible to
exceed.  We can play some games to increase the size of each batch and
possibly reduce the likelihood of a dump being split but we can't
guarantee that it will be atomic.  I guess if we have multiple
important threads (i.e. not ovs-dpctl), userspace will have to do its
own synchronization.  It does seem that NLM_F_ATOMIC would be the
solution but you're right that it isn't implemented.

For this patch then:
Acked-by: Jesse Gross <jesse at nicira.com>




More information about the dev mailing list