[ovs-dev] knowing when a kernel flow is really deleted

[Ben Pfaff]

On Thu, Dec 15, 2011 at 03:46:11PM -0800, Ben Pfaff wrote:
> On Thu, Dec 15, 2011 at 03:24:38PM -0800, Jesse Gross wrote:
> > On Thu, Dec 15, 2011 at 1:34 PM, Ben Pfaff <blp at nicira.com> wrote:
> > > On Thu, Dec 15, 2011 at 01:00:00PM -0800, Jesse Gross wrote:
> > >> On Thu, Dec 15, 2011 at 12:34 PM, Ben Pfaff <blp at nicira.com> wrote:
> > >> > A workaround would be to call synchronize_rcu() and send the genl
> > >> > reply from some context that doesn't hold genl_lock, but that's hardly
> > >> > elegant. ??Also it means that the real reply would come after the one
> > >> > generated automatically by af_netlink.c when NLM_F_ACK is used, which
> > >> > violates the normal rules.
> > >>
> > >> Isn't that almost exactly the same as sending the message from the RCU
> > >> callback (including the Netlink ordering issue)?
> > >
> > > In the "send from RCU callback" case, I intended that the normal
> > > Netlink reply would be sent synchronously just after deletion, just as
> > > it is now. ??The ordering would therefore stay just as it is now. ??Only
> > > the broadcast reply would be deferred.
> > 
> > What do you consider the "normal Netlink reply"?  There are basically
> > 3 different pieces:
> > 
> >  * Multicast flow information to the relevant group (excluding the
> > requester if NLM_F_ECHO is specified).
> >  * Unicast flow information to the requester if NLM_F_ECHO is specified.
> >  * Unicast Netlink acknowledgement if NLM_F_ACK is specified or there
> > was an error.
> > 
> > Are you talking about doing the last two as-is and moving the
> > multicast to the flow reclamation (but actually sending it to everyone
> > at that time)?
> 
> Yes, that's roughly what I had in mind, and perhaps exactly, depending
> on what "but actually sending it everyone" means.  The idea is that
> the immediate, synchronous reply for NLM_F_ECHO would give approximate
> statistics, the later multicast would give exact statistics, and
> receiving the multicast could be used as an indicator that any upcalls
> generated by the flow have already been queued to userspace.
> 
> I assumed one socket would be used for sending the request and
> receiving the unicast reply and another socket would be used for
> receiving the multicasts, since we'd want to get both separately.
> 
> > > The "use synchronize_rcu() on the side then send the reply" case would
> > > change the message ordering.
> > 
> > I guess I don't see why you couldn't use exactly the same strategy as
> > you choose above.
> 
> I assumed that an intended advantage of using synchronize_rcu() was
> that all three forms

...would have the same, correct contents.  Otherwise there's no
advantage at all versus sending the reply from the flow reclamation
callback.