[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLhd2Y0Htwx_kO7RixXPrPviBngZxngeMgN5n2zBTNG-w@mail.gmail.com>
Date: Tue, 18 Nov 2025 00:32:29 -0800
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
Kuniyuki Iwashima <kuniyu@...gle.com>, netdev@...r.kernel.org, eric.dumazet@...il.com,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Subject: Re: [PATCH v3 net-next 3/3] net: use napi_skb_cache even in process context
On Mon, Nov 17, 2025 at 6:07 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Mon, Nov 17, 2025 at 10:31 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > On Mon, Nov 17, 2025 at 5:48 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > >
> >
> > >
> > > We can add a static key to enable/disable the behaviors that are most
> > > suited to a particular workload.
> >
> > Are we going to introduce a new knob to control this snippet in
> > napi_consume_skb()?
>
> That's it. For single flow in xsk scenarios, adding something like a
> static key to avoid 1) using napi_skb_cache_get() in this patch, 2)
> deferring free in commit [3] can contribute to a higher performance
> back to more than 1,900,000 pps. I have no clue if adding a new sysctl
> is acceptable.
I will add one as soon as this series is merged.
Powered by blists - more mailing lists