On 2021-01-08 2:21 p.m., Shannon Nelson wrote:
On 1/8/21 10:26 AM, Jesse Brandeburg wrote:
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
On Fri, 2021-01-08 at 11:21 -0800, Shannon Nelson wrote:
> On 1/8/21 10:26 AM, Jesse Brandeburg wrote:
> > 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 c
On 1/8/21 10:26 AM, Jesse Brandeburg wrote:
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
Eric Dumazet wrote:
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6071,6 +6071,7 @@ static gro_result_t napi_skb_finish(struct
> > napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> >
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. T
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
t
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
