* netif_receive_skb return value in bridging scenario
@ 2013-02-26 14:57 Bercaru Cristian-B43982
2013-02-26 16:35 ` Eric Dumazet
0 siblings, 1 reply; 2+ messages in thread
From: Bercaru Cristian-B43982 @ 2013-02-26 14:57 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello!
I noticed that the return value of __netif_receive_skb is initialized to NET_RX_DROP.
If the bridging code handles the packet and successfully returns RX_HANDLER_CONSUMED, __netif_receive_skb returns the default value, NET_RX_DROP. I don't think it is fair to consider the packet dropped, since it is received successfully.
I thought the return value of __netif_receive_skb was used by Ethernet NIC drivers for updating their RX_DROP and RX_OX counters, but I studied the source code of various drivers and they seem to ignore whatever the return value. It seems strange. Then shouldn't the function header look like " void netif_receive_skb(... " ?
Thank you,
Cristian Bercaru
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: netif_receive_skb return value in bridging scenario
2013-02-26 14:57 netif_receive_skb return value in bridging scenario Bercaru Cristian-B43982
@ 2013-02-26 16:35 ` Eric Dumazet
0 siblings, 0 replies; 2+ messages in thread
From: Eric Dumazet @ 2013-02-26 16:35 UTC (permalink / raw)
To: Bercaru Cristian-B43982; +Cc: netdev@vger.kernel.org
On Tue, 2013-02-26 at 14:57 +0000, Bercaru Cristian-B43982 wrote:
> Hello!
>
> I noticed that the return value of __netif_receive_skb is initialized
> to NET_RX_DROP.
>
> If the bridging code handles the packet and successfully returns
> RX_HANDLER_CONSUMED, __netif_receive_skb returns the default value,
> NET_RX_DROP. I don't think it is fair to consider the packet dropped,
> since it is received successfully.
>
> I thought the return value of __netif_receive_skb was used by Ethernet
> NIC drivers for updating their RX_DROP and RX_OX counters, but I
> studied the source code of various drivers and they seem to ignore
> whatever the return value. It seems strange. Then shouldn't the
> function header look like " void netif_receive_skb(... " ?
It seems better to factorize whatever is needed in core network layer,
instead of adding code in all drivers to check netif_receive_skb()
return code.
Check the follwing "atomic_long_inc(&skb->dev->rx_dropped);"
in __netif_receive_skb_core()
For the case you mention, I guess we need the following patch
diff --git a/net/core/dev.c b/net/core/dev.c
index 17bc535..e98fb4d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3446,6 +3446,7 @@ ncls:
}
switch (rx_handler(&skb)) {
case RX_HANDLER_CONSUMED:
+ ret = NET_RX_SUCCESS;
goto unlock;
case RX_HANDLER_ANOTHER:
goto another_round;
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-02-26 16:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-26 14:57 netif_receive_skb return value in bridging scenario Bercaru Cristian-B43982
2013-02-26 16:35 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox