Query on Rx Frame processing

[michi1 at michaelblizek.twilightparadox.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