From: michi1@michaelblizek.twilightparadox.com (michi1 at michaelblizek.twilightparadox.com)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Query on Rx Frame processing
Date: Sat, 15 Oct 2011 21:28:07 +0200 [thread overview]
Message-ID: <20111015192806.GC2282@grml> (raw)
In-Reply-To: <CAOUxTKMYRqNesw6_dRbD0R4JT9Y_44P22G3xLn-DFP+0PqEz4Q@mail.gmail.com>
Hi!
On 19:45 Sat 15 Oct , amit mehta wrote:
...
> Now in step 4 above, driver passes this packet to the
> network layer by calling netif_receive_skb() which may return
> NET_RX_DROP (packet was dropped), but most
> (I checked some of the network driver code) of the network
> drivers do not do this check.
> Hence,
> Q1: Shouldn't drivers be doing that ?
The return value NET_RX_DROP seems to be used in various places where no
congestion exists:
http://lxr.linux.no/linux+v3.0.4/net/ipv4/ip_forward.c#L131
http://lxr.linux.no/linux+v3.0.4/net/ipv4/ip_input.c#L369
http://lxr.linux.no/linux+v3.0.4/net/ipv4/ip_input.c#L451
What should network drivers do with this info?
Also, there might be multiple layer 3 protocols. If one of them would signal
congestion, should the driver slow down receiving?
Maybe the question is rather why does this variable exist at all. I guess it
is just to got statistic data.
> Q2: Suppose the Card keeps pushing the frames at very high rate
> (10 Gig adapters are already in the market and maybe in near future
> we might have even faster ethernet adapters) then how the driver
> and the networking stack will handle such rapid frames arrivals?
> Will NAPI, interrupt coalescing be enough ?
It seems like net_rx_action does some throttling:
http://lxr.linux.no/linux+v3.0.4/net/core/dev.c#L3764
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
prev parent reply other threads:[~2011-10-15 19:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 14:15 Query on Rx Frame processing amit mehta
2011-10-15 19:28 ` michi1 at michaelblizek.twilightparadox.com [this message]
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=20111015192806.GC2282@grml \
--to=michi1@michaelblizek.twilightparadox.com \
--cc=kernelnewbies@lists.kernelnewbies.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.