[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <436709.64173.qm@web180305.mail.gq1.yahoo.com>
Date: Sun, 5 Sep 2010 14:35:15 -0700 (PDT)
From: David Brownell <david-b@...bell.net>
To: Ondrej Zary <linux@...nbow-software.org>
Cc: David Brownell <dbrownell@...rs.sourceforge.net>,
netdev@...r.kernel.org,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usbnet: allow rx_process() to ignore packets
> > > From: Ondrej Zary <linux@...nbow-software.org>
> > > Subject: [PATCH] usbnet: allow rx_process() to
> ignore packets
> >
> > It already can ... I'm already not
> > liking this patch...
You didn't explain why "ignore". As a rule, if
the network peer is sending garbage, that needs
to be accounted as an error, not igored. You seem
to be complaining about accounting garbage as such.
rx_process() knows only two cases:
> either rx_fixup()
> returns 0 or a non-zero value. If I return 0,
> the error counter is incremented.
So don't return zero, when you're not trying to
indicate an error. ... easy.
> If I return non-zero value, packet is
> processed ("passed up the
> stack" - usbnet_skb_return() called)
> if the skb has non-zero length,
Exactly -- that's how the minidriver says that
it stripped framing off the packet, so other
code should pass the packet up the stack.
Have you tried emptying the SKB (len zero) to
indicate you've consumed all of its contents?
(Or in your case, "ignored"). That would seem to
be more like what you want to do ... ISTR that the
network stack cleanly handles empty SKBs; if not,
maybe it should.
There's no way
> to not pass the
> packet up the stack without incrementing the error
> counter.
If rx_fixup leaves a single packet in SKB, that
gets passed up the stack. and not treated as any
kind of error.
>
> > You've not convinced me this is even necessary.
> >
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists