From: John Fastabend <john.r.fastabend@intel.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-net-drivers@solarflare.com,
Shradha Shah <sshah@solarflare.com>
Subject: Re: [PATCH net-next 19/19] sfc: Add SR-IOV back-end support for SFC9000 family
Date: Wed, 15 Feb 2012 17:18:18 -0800 [thread overview]
Message-ID: <4F3C595A.3020401@intel.com> (raw)
In-Reply-To: <1329353550.2565.45.camel@bwh-desktop>
On 2/15/2012 4:52 PM, Ben Hutchings wrote:
> On the SFC9000 family, each port has 1024 Virtual Interfaces (VIs),
> each with an RX queue, a TX queue, an event queue and a mailbox
> register. These may be assigned to up to 127 SR-IOV virtual functions
> per port, with up to 64 VIs per VF.
>
> We allocate an extra channel (IRQ and event queue only) to receive
> requests from VF drivers.
>
> There is a per-port limit of 4 concurrent RX queue flushes, and queue
> flushes may be initiated by the MC in response to a Function Level
> Reset (FLR) of a VF. Therefore, when SR-IOV is in use, we submit all
> flush requests via the MC.
>
> The RSS indirection table is shared with VFs, so the number of RX
> queues used in the PF is limited to the number of VIs per VF.
>
> This is almost entirely the work of Steve Hodgson, formerly
> shodgson@solarflare.com.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
Hi Ben,
So how would multiple VIs per VF work? Looks like each VI has a TX/RX
pair all bundled under a single netdev with some set of TX MAC filters.
Do you expect users to build tc rules and edit the queue_mapping to get
the skb headed at the correct tx queue? Would it be better to model each
VI has its own net device.
Thanks,
John
next prev parent reply other threads:[~2012-02-16 1:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-16 0:42 pull request: sfc-next 2012-02-16 Ben Hutchings
2012-02-16 0:44 ` [PATCH net-next 01/19] sfc: Skip RX end-of-batch work on channels without an RX queue Ben Hutchings
2012-02-16 0:44 ` [PATCH net-next 02/19] sfc: Do not retry hardware probe if it schedules a reset Ben Hutchings
2012-02-16 0:45 ` [PATCH net-next 03/19] sfc: Replace some literal constants with EFX_PAGE_SIZE/EFX_BUF_SIZE Ben Hutchings
2012-02-16 0:45 ` [PATCH net-next 04/19] sfc: Warn if unable to create MTDs Ben Hutchings
2012-02-16 0:46 ` [PATCH net-next 05/19] sfc: Add support for configuring RX unicast/multicast default filters Ben Hutchings
2012-02-16 0:46 ` [PATCH net-next 06/19] sfc: Add support for TX MAC filters Ben Hutchings
2012-02-16 0:47 ` [PATCH net-next 07/19] sfc: Correct MAC filter bitfield definitions Ben Hutchings
2012-02-16 0:47 ` [PATCH net-next 08/19] sfc: Generalise driver event generation Ben Hutchings
2012-02-16 0:47 ` [PATCH net-next 09/19] sfc: Generate RX fill events based on RX queues, not channels Ben Hutchings
2012-02-16 0:48 ` [PATCH net-next 10/19] sfc: Leave interrupts and event queues enabled whenever we can Ben Hutchings
2012-02-16 0:48 ` [PATCH net-next 11/19] sfc: Use proper function to test for RX channel in efx_poll() Ben Hutchings
2012-02-16 0:48 ` [PATCH net-next 12/19] sfc: Generalise event generation to cover VF-owned event queues Ben Hutchings
2012-02-16 0:49 ` [PATCH net-next 13/19] sfc: Disable flow control during flushes Ben Hutchings
2012-02-16 0:49 ` [PATCH net-next 14/19] sfc: Make buffer table indices and counts consistently unsigned Ben Hutchings
2012-02-16 0:50 ` [PATCH net-next 15/19] sfc: Make all CPU/IRQ/channel/queue counts unsigned Ben Hutchings
2012-02-16 0:50 ` [PATCH net-next 16/19] sfc: Add support for 'extra' channel types Ben Hutchings
2012-02-16 0:51 ` [PATCH net-next 17/19] sfc: Pass NIC structure into efx_wanted_parallelism() Ben Hutchings
2012-02-16 0:52 ` [PATCH net-next 18/19] sfc: Allocate SRAM between buffer table and descriptor caches at init time Ben Hutchings
2012-02-16 0:52 ` [PATCH net-next 19/19] sfc: Add SR-IOV back-end support for SFC9000 family Ben Hutchings
2012-02-16 1:18 ` John Fastabend [this message]
2012-02-16 1:57 ` Ben Hutchings
2012-02-21 19:52 ` John Fastabend
2012-02-21 20:24 ` Ben Hutchings
2012-02-16 22:08 ` pull request: sfc-next 2012-02-16 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=4F3C595A.3020401@intel.com \
--to=john.r.fastabend@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=linux-net-drivers@solarflare.com \
--cc=netdev@vger.kernel.org \
--cc=sshah@solarflare.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).