[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49E89AC6.80409@cosmosbay.com>
Date: Fri, 17 Apr 2009 17:05:42 +0200
From: Eric Dumazet <dada1@...mosbay.com>
To: Stephen Hemminger <shemminger@...tta.com>
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] loopback: better handling of packet drops
Stephen Hemminger a écrit :
> On Fri, 17 Apr 2009 12:33:33 +0200
> Eric Dumazet <dada1@...mosbay.com> wrote:
>> static int loopback_xmit(struct sk_buff *skb, struct net_device *dev)
>> {
>> struct pcpu_lstats *pcpu_lstats, *lb_stats;
>> + int len;
>>
>> skb_orphan(skb);
>>
>> - skb->protocol = eth_type_trans(skb,dev);
>> + skb->protocol = eth_type_trans(skb, dev);
>>
>> /* it's OK to use per_cpu_ptr() because BHs are off */
>> pcpu_lstats = dev->ml_priv;
>> lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
>> - lb_stats->bytes += skb->len;
>> - lb_stats->packets++;
>>
>> - netif_rx(skb);
>> + len = skb->len;
>> + if (likely(__netif_rx(skb) == NET_RX_SUCCESS)) {
>> + lb_stats->bytes += len;
>> + lb_stats->packets++;
>> + return NETDEV_TX_OK;
>> + }
>> + lb_stats->drops++;
>>
>> - return 0;
>> + return NETDEV_TX_BUSY;
>> }
>
> If you return NETDEV_TX_BUSY, then the xmit logic will retry
> so it is not really a drop but a stall. I think it is confusing
> to call this a packet loss.
Good point, thanks.
So we should not account this stall in dev stats ? Maybe in 'collisions' ?
I also discovered we had to do
skb_push(skb, ETH_HLEN); /* undo the skb_pull() done in eth_type_trans() */
before returning NETDEV_TX_BUSY;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists