Re: [UDP6]: Restore sk_filter optimisation

[Mitsuru Chinen <mitch@linux.vnet.ibm.com>]

On Wed, 31 Oct 2007 22:42:57 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Wed, Oct 31, 2007 at 11:05:45PM +0900, Mitsuru Chinen wrote:
> >
> > > >  1. udp6InDatagrams is incremented instead of udpInErrors
> > > >  2. In userland, recvfrom() replies an error with EAGAIN.
> > > >     recvfrom() wasn't aware of such a packet before.
> > > > 
> > > > Are these changes intentional?
> >
> > As far as I tested, this doesn't happen with the old code even if
> > a filter is attached. However, this happen with the new code
> > without a filter and I don't see this rather when a filter is
> > attached. So, I'm afraid it's new.
> 
> Sorry, I read the patch the wrong way around :)
> 
> 1) is just an accounting issue.  It shouldn't be too difficult
> to fix it up.  In fact, I think udpInErrors will still be
> incremented once we detect the error.
> 
> 2) shouldn't be an issue because we've already solved the
> problem by making poll/select do the checksum verification
> before indiciating that the socket is readable.
> 
> > > And, we're not sure how much the "optimization"'s benefit is.
> > > It is even worse when we are hand
> 
> The checksum verification is costly because we have to bring
> the payload into cache.  Since filters are very rare it's
> worthwhile to postpone the checksum verification for the common
> case.
> 
> Also as a general rule, we want to avoid divergent behaviour
> between IPv4 and IPv6.  So for changes like this we should
> really modify both stacks in future rather than have each
> stack do its own thing.

I got it. OK. I will submit a patch to postpone the udpInError
counter incrementation, either.

Thanks for your detailed explanation!

Best Regards,
----
Mitsuru Chinen <mitch@linux.vnet.ibm.com>