[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210108102630.00004202@intel.com>
Date: Fri, 8 Jan 2021 10:26:30 -0800
From: Jesse Brandeburg <jesse.brandeburg@...el.com>
To: Shannon Nelson <snelson@...sando.io>
Cc: netdev@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
Eric Dumazet <edumazet@...gle.com>,
Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH net-next v1 1/2] net: core: count drops from GRO
Shannon Nelson wrote:
> On 1/6/21 1:55 PM, Jesse Brandeburg wrote:
> > When drivers call the various receive upcalls to receive an skb
> > to the stack, sometimes that stack can drop the packet. The good
> > news is that the return code is given to all the drivers of
> > NET_RX_DROP or GRO_DROP. The bad news is that no drivers except
> > the one "ice" driver that I changed, check the stat and increment
>
> If the stack is dropping the packet, isn't it up to the stack to track
> that, perhaps with something that shows up in netstat -s? We don't
> really want to make the driver responsible for any drops that happen
> above its head, do we?
I totally agree!
In patch 2/2 I revert the driver-specific changes I had made in an
earlier patch, and this patch *was* my effort to make the stack show the
drops.
Maybe I wasn't clear. I'm seeing packets disappear during TCP
workloads, and this GRO_DROP code was the source of the drops (I see it
returning infrequently but regularly)
The driver processes the packet but the stack never sees it, and there
were no drop counters anywhere tracking it.
Powered by blists - more mailing lists