All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Zary <linux@rainbow-software.org>
To: David Brownell <david-b@pacbell.net>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
	netdev@vger.kernel.org,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usbnet: allow rx_process() to ignore packets
Date: Tue, 7 Sep 2010 22:02:16 +0200	[thread overview]
Message-ID: <201009072202.18703.linux@rainbow-software.org> (raw)
In-Reply-To: <436709.64173.qm@web180305.mail.gq1.yahoo.com>

On Sunday 05 September 2010 23:35:15 David Brownell wrote:
> > > > From: Ondrej Zary <linux@rainbow-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.

It's not a garbage, just a packet that is not yet complete.

>  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 1, the incomplete packet would be passed up the stack.

> > 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.

Yes, I have tried it - in fact, this is that cx82310_eth does now. It does not 
work because rx_process() in usbnet.c checks if the skb is empty - and 
increments the error counter if it is. Maybe it should not?

-- 
Ondrej Zary

  reply	other threads:[~2010-09-07 20:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-04 21:52 [PATCH] usbnet: allow rx_process() to ignore packets Ondrej Zary
2010-09-04 23:24 ` David Brownell
2010-09-05 16:16   ` Ondrej Zary
2010-09-05 21:35     ` David Brownell
2010-09-07 20:02       ` Ondrej Zary [this message]
2010-09-10 21:35       ` [PATCH v2] usbnet: do not count empty skbs as errors in rx_process() Ondrej Zary
2010-09-11 19:07         ` David Brownell
2010-09-11 20:22           ` Ondrej Zary
2010-09-11 21:15             ` David Brownell
2010-09-11 21:21               ` Ondrej Zary
  -- strict thread matches above, loose matches on Subject: below --
2010-09-08  0:46 [PATCH] usbnet: allow rx_process() to ignore packets David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201009072202.18703.linux@rainbow-software.org \
    --to=linux@rainbow-software.org \
    --cc=david-b@pacbell.net \
    --cc=dbrownell@users.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.