From: David Brownell <david-b@pacbell.net>
To: Ondrej Zary <linux@rainbow-software.org>
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 17:46:04 -0700 (PDT) [thread overview]
Message-ID: <621591.67832.qm@web180301.mail.gq1.yahoo.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
--- On Tue, 9/7/10, Ondrej Zary <linux@rainbow-software.org> wrote:
>
> It's not a garbage, just a packet that is not yet
> complete.
Sorry, I guess I was being dense.
I thought packets were by definition complete... :)
I think you're saying this is one of N fragments
which the minidriver will be re-assembling into
a bigger packet, before somehow passing it up
the stack...
I attach my doc update patch. (should be the
same as what I sent before. Consider my apology
for using an attachment as repeated here; my email
setup remains partly broken). Can you send
a version of your defrag-enabling patch which
applies on top of it, and documents your new
calling convention (with a third return case
for rx_process() too?
[-- Attachment #2: rxfix --]
[-- Type: application/octet-stream, Size: 2492 bytes --]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Subject: usbnet: doc updates
Provide more documentation about the rx_fixup() calling convention,
to help reduce some recently-observed confusion.
Also summarize the equivalence of USB and network TX/RX queues, to
help highlight the roles of the fixup() routines with link protocols
using the CPU-intensive packet batching models.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
include/linux/usb/usbnet.h | 31 +++++++++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -22,8 +22,22 @@
#ifndef __LINUX_USB_USBNET_H
#define __LINUX_USB_USBNET_H
-/* interface from usbnet core to each USB networking link we handle */
+/** interface from usbnet core to each USB networking link we handle.
+ *
+ * Note that the design center for usbnet has one IEEE packet per URB,
+ * and maps network TX and RX queues directly to the
+ * USB hardware TX/RX queues, minimizing software and hardware overhead.
+ * Some link protocols (like RNDIS and CDC NCM) promote less efficient
+ * designs which involve batching multiple IEEE packets in each URB,
+ * with increased TX overhead to copy IEEE packets into TX URBs' data
+ * buffers in tx_fixup() routines, plus unbatching work in rx_fixup() too.
+ * Sometimes the TX overhead can be minimized on Linux by not batching, but
+ * this usually won't work for RX because of the need to interoperate with
+ * implementations which batch on TX.
+ */
+
struct usbnet {
+
/* housekeeping */
struct usb_device *udev;
struct usb_interface *intf;
@@ -113,7 +127,20 @@ struct driver_info {
/* link reset handling, called from defer_kevent */
int (*link_reset)(struct usbnet *);
- /* fixup rx packet (strip framing) */
+ /* fixup rx packet ( by stripping framing from URB/SKB.
+ *
+ * If SKB batches one or more packets, pass all but one of them
+ * up the stack (clone SKB and fixup each clone before netif_rx)).
+ *
+
+ * When you leave one packet in SKB (intended usage), return
+ * nonzero and ensure skb-len is nonzero. the packet will be
+ * passed up the network stack and accounted properly.
+ *
+ * return zero to indicate errors such as too much header or
+ * data, or a bad checksum; the packet will be dropped
+ * and accounted as an error.
+ */
int (*rx_fixup)(struct usbnet *dev, struct sk_buff *skb);
/* fixup tx packet (add framing) */
next reply other threads:[~2010-09-08 0:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 0:46 David Brownell [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-09-04 21:52 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
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=621591.67832.qm@web180301.mail.gq1.yahoo.com \
--to=david-b@pacbell.net \
--cc=dbrownell@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rainbow-software.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®