From: Shannon Nelson <snelson@pensando.io>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next 0/9] ionic: Add support for Event Queues
Date: Tue, 18 Feb 2020 08:16:43 -0800 [thread overview]
Message-ID: <e739ddaf-e04b-302e-9ca2-1700385bc379@pensando.io> (raw)
In-Reply-To: <20200217.140344.810813375227195875.davem@davemloft.net>
On 2/17/20 2:03 PM, David Miller wrote:
> From: Shannon Nelson <snelson@pensando.io>
> Date: Sun, 16 Feb 2020 22:55:22 -0800
>
>> On 2/16/20 8:11 PM, David Miller wrote:
>>> From: Shannon Nelson <snelson@pensando.io>
>>> Date: Sun, 16 Feb 2020 15:11:49 -0800
>>>
>>>> This patchset adds a new EventQueue feature that can be used
>>>> for multiplexing the interrupts if we find that we can't get
>>>> enough from the system to support our configuration. We can
>>>> create a small number of EQs that use interrupts, and have
>>>> the TxRx queue pairs subscribe to event messages that come
>>>> through the EQs, selecting an EQ with (TxIndex % numEqs).
>>> How is a user going to be able to figure out how to direct
>>> traffic to specific cpus using multiqueue settings if you're
>>> going to have the mapping go through this custom muxing
>>> afterwards?
>> When using the EQ feature, the TxRx are assigned to the EventQueues in
>> a straight round-robin, so the layout is predictable. I suppose we
>> could have a way to print out the TxRx -> EQ -> Irq mappings, but I'm
>> not sure where we would put such a thing.
> No user is going to know this and it's completely inconsistent with how
> other multiqueue networking devices behave.
The ionic's main RSS set is limited to number of cpus, so that in normal
use we remain consistent with other drivers. With no additional
configuration, this is the standard behavior, as expected, so most users
won't need to know or care.
We have a FW configuration option that can be chosen by the customer to
make use of the much larger set of queues that we have available. This
keeps the RSS set limited to the cpu count or less, keeping normal use
consistent, and makes additional queues available for macvlan offload
use. Depending on the customer's configuration, this can be 100's of
queues, which seems excessive, but we have been given use-cases for
them. In these cases, the queues will be wrapped around the vectors
available with the customer's use case. This is similar to the Intel
i40e's support for macvlan offload which can also end up wrapping
around, but they have the number of offload channels constrained to a
much smaller number.
(BTW, with the ixgbe we can do an ethtool set_channel to get more queues
than vectors on the PF, which will end up up wrapping the queues around
the vectors allocated. Not extremely useful perhaps, but possible.)
We don't have support for the macvlan offload in this upstream driver
yet, but this patchset allows us to play nicely with that FW configuration.
sln
next prev parent reply other threads:[~2020-02-18 16:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-16 23:11 [PATCH net-next 0/9] ionic: Add support for Event Queues Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 1/9] ionic: change param from lif to ionic Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 2/9] ionic: rename rdma eqs field Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 3/9] ionic: replace lif list with xarray Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 4/9] ionic: add event queue definitions to hw interface Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 5/9] ionic: rename napi irq functions Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 6/9] ionic: add functions for setup and tear down event queues Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 7/9] ionic: add q ident query for eq Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 8/9] ionic: add basic eq support Shannon Nelson
2020-02-16 23:11 ` [PATCH net-next 9/9] ionic: keep ionic dev on lif init fail Shannon Nelson
2020-02-17 4:11 ` [PATCH net-next 0/9] ionic: Add support for Event Queues David Miller
2020-02-17 6:55 ` Shannon Nelson
2020-02-17 22:03 ` David Miller
2020-02-18 16:16 ` Shannon Nelson [this message]
2020-02-18 20:33 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e739ddaf-e04b-302e-9ca2-1700385bc379@pensando.io \
--to=snelson@pensando.io \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.