[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200630200801.4uejth6qawnebyou@bsd-mbp.dhcp.thefacebook.com>
Date: Tue, 30 Jun 2020 13:08:01 -0700
From: Jonathan Lemon <jonathan.lemon@...il.com>
To: Maxim Mikityanskiy <maximmi@...lanox.com>
Cc: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
Amritha Nambiar <amritha.nambiar@...el.com>,
Kiran Patil <kiran.patil@...el.com>,
Alexander Duyck <alexander.h.duyck@...el.com>,
Eric Dumazet <edumazet@...gle.com>,
Tom Herbert <tom@...bertland.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ADQ - comparison to aRFS, clarifications on NAPI ID, binding
with busy-polling
On Fri, Jun 26, 2020 at 12:48:06PM +0000, Maxim Mikityanskiy wrote:
> Thanks a lot for your reply! It was really helpful. I have a few
> comments, please see below.
>
> On 2020-06-24 23:21, Samudrala, Sridhar wrote:
>
> > ADQ also provides 2 levels of filtering compared to aRFS+XPS. The first
> > level of filtering selects a queue-set associated with the application
> > and the second level filter or RSS will select a queue within that queue
> > set associated with an app thread.
>
> This difference looks important. So, ADQ reserves a dedicated set of
> queues solely for the application use.
I wanted to break this out as it looks like the most interesting part.
There are several use cases where the application needs to have its
packets arrive on a specific queue (or queue set): AF_XDP, and other
zero-copy work.
Having the app bind to a napi_id doesn't seem to provide the same
functionality.
> Ethtool RSS context API (look for "context" in man ethtool) seems more
> appropriate for the RX side for this purpose.
Agreed.
--
Jonathan
Powered by blists - more mailing lists