From: Or Gerlitz <gerlitz.or@gmail.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: David Miller <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>,
oss-drivers@netronome.com, Andy Gospodarek <gospo@broadcom.com>,
linux-internal <linux-internal@mellanox.com>
Subject: Re: [PATCH net-next 00/13] nfp: abm: add basic support for advanced buffering NIC
Date: Tue, 22 May 2018 17:50:45 +0300 [thread overview]
Message-ID: <CAJ3xEMhfZjKKRGZOJ8CvrbDEQ9jh9kYvZ-aJBsC86ixm+1RnWw@mail.gmail.com> (raw)
In-Reply-To: <CAJpBn1ywEO2MayK=EvzzLYLXfZ2xuWCfyiaAYLtL-gnrj2gKwQ@mail.gmail.com>
On Tue, May 22, 2018 at 10:56 AM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Mon, May 21, 2018 at 11:32 PM, Or Gerlitz wrote:
>> On Tue, May 22, 2018 at 8:12 AM, Jakub Kicinski wrote:
>>> Hi!
>>>
>>> This series lays groundwork for advanced buffer management NIC feature.
>>> It makes necessary NFP core changes, spawns representors and adds devlink
>>> glue. Following series will add the actual buffering configuration (patch
>>> series size limit).
>>>
>>> First three patches add support for configuring NFP buffer pools via a
>>> mailbox. The existing devlink APIs are used for the purpose.
>>>
>>> Third patch allows us to perform small reads from the NFP memory.
>>>
>>> The rest of the patch set adds eswitch mode change support and makes
>>> the driver spawn appropriate representors.
>>
>> Hi Jakub,
>>
>> Could you provide more higher level description on the abm use-case
>> and nature of these representors? I understand that under abm you are
>> modeling the nic as switch with vNIC ports, does vNIC port and vNIC
>> port rep have the same characteristics as VF and VF rep (xmit on one side
>> <--> send on 2nd side), does traffic is to be offloaded using TC, etc.
>> What one would be doing with vNIC instance, hand it to container ala the Intel
>> VMDQ concept?
>> can this be seen as veth HW offload? etc
> Yes, the reprs can be used like VF reprs but that's not the main use
> case. We are targeting container world with ABM, so no VFs and no
> SR-IOV. There is only one vNIC per port and no veth offload etc. In
one vNIC for multiple containers? or you have a (v?) port per container?
> In the most basic scenario with 1 PF corresponding to 1 port there is no
> real use for switching.
multiple containers? please clarify it a little better
> The main purpose here is that we want to setup the buffering and QoS
> inside the NIC (both for TX and RX) and then use eBPF to perform
> filtering, queue assignment and per-application RSS. That's pretty
> much it at this point.
> Switching if any will be a basic bridge offload. QoS configuration
> will all be done using TC qdisc offload, RED etc. exactly like mlxsw :)
I guess I'll understand it better once you clarify the multiple
containers thing,
thanks for the details and openness
next prev parent reply other threads:[~2018-05-22 14:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 5:12 [PATCH net-next 00/13] nfp: abm: add basic support for advanced buffering NIC Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 01/13] nfp: move rtsym helpers to pf code Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 02/13] nfp: add support for per-PCI PF mailbox Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 03/13] nfp: add shared buffer configuration Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 04/13] nfp: core: allow 4-byte aligned accesses to Memory Units Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 05/13] nfp: abm: add initial active buffer management NIC skeleton Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 06/13] nfp: abm: create project-specific vNIC structure Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 07/13] nfp: add app pointer to port representors Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 08/13] devlink: don't take instance lock around eswitch mode set Jakub Kicinski
2018-05-22 8:41 ` Jiri Pirko
2018-05-22 5:12 ` [PATCH net-next 09/13] nfp: add devlink_eswitch_mode_set callback Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 10/13] nfp: abm: spawn port netdevs Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 11/13] nfp: abm: force Ethternet port up Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 12/13] nfp: use split in naming of PCIe PF ports Jakub Kicinski
2018-05-22 5:12 ` [PATCH net-next 13/13] nfp: assign vNIC id as phys_port_name of vNICs which are not ports Jakub Kicinski
2018-05-22 6:32 ` [PATCH net-next 00/13] nfp: abm: add basic support for advanced buffering NIC Or Gerlitz
2018-05-22 7:56 ` Jakub Kicinski
2018-05-22 14:50 ` Or Gerlitz [this message]
2018-05-22 19:14 ` Jakub Kicinski
2018-05-23 18:28 ` 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=CAJ3xEMhfZjKKRGZOJ8CvrbDEQ9jh9kYvZ-aJBsC86ixm+1RnWw@mail.gmail.com \
--to=gerlitz.or@gmail.com \
--cc=davem@davemloft.net \
--cc=gospo@broadcom.com \
--cc=jakub.kicinski@netronome.com \
--cc=linux-internal@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.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).