On Tue, May 22, 2018 at 10:56 AM, Jakub Kicinski <jakub.kicin...@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
