netdev - Re: [RFC] current devlink extension plan for NICs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Mar 2020 15:37:14 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, parav@...lanox.com,
        yuvalav@...lanox.com, jgg@...pe.ca, saeedm@...lanox.com,
        leon@...nel.org, andrew.gospodarek@...adcom.com,
        michael.chan@...adcom.com, moshe@...lanox.com, ayal@...lanox.com,
        eranbe@...lanox.com, vladbu@...lanox.com, kliteyn@...lanox.com,
        dchickles@...vell.com, sburla@...vell.com, fmanlunas@...vell.com,
        tariqt@...lanox.com, oss-drivers@...ronome.com,
        snelson@...sando.io, drivers@...sando.io, aelior@...vell.com,
        GR-everest-linux-l2@...vell.com, grygorii.strashko@...com,
        mlxsw@...lanox.com, idosch@...lanox.com, markz@...lanox.com,
        jacob.e.keller@...el.com, valex@...lanox.com,
        linyunsheng@...wei.com, lihong.yang@...el.com,
        vikas.gupta@...adcom.com, magnus.karlsson@...el.com
Subject: Re: [RFC] current devlink extension plan for NICs

Mon, Mar 23, 2020 at 08:21:23PM CET, kuba@...nel.org wrote:
>> >> >> Note that the PF is merged with physical port representor.
>> >> >> That is due to simpler and flawless transition from legacy mode and back.
>> >> >> The devlink_ports and netdevs for physical ports are staying during
>> >> >> the transition.    
>> >> >
>> >> >When users put an interface under bridge or a bond they have to move 
>> >> >IP addresses etc. onto the bond. Changing mode to "switchdev" is a more
>> >> >destructive operation and there should be no expectation that
>> >> >configuration survives.    
>> >> 
>> >> Yeah, I was saying the same thing when our arch came up with this, but
>> >> I now think it is just fine. It is drivers responsibility to do the
>> >> shift. And the entities representing the uplink port: netdevs and
>> >> devlink_port instances. They can easily stay during the transition. The
>> >> transition only applies to the eswitch and VF entities.  
>> >
>> >If PF is split from the uplink I think the MAC address should stay with
>> >the PF, not the uplink (which becomes just a repr in a Host case).
>> >  
>> >> >The merging of the PF with the physical port representor is flawed.    
>> >> 
>> >> Why?  
>> >
>> >See below.
>> >  
>> >> >People push Qdisc offloads into devlink because of design shortcuts
>> >> >like this.    
>> >> 
>> >> Could you please explain how it is related to "Qdisc offloads"  
>> >
>> >Certain users have designed with constrained PCIe bandwidth in the
>> >server. Meaning NIC needs to do buffering much like a switch would.
>> >So we need to separate the uplink from the PF to attach the Qdisc
>> >offload for configuring details of PCIe queuing.  
>> 
>> Hmm, I'm not sure I understand. Then PF and uplink is the same entity,
>> you can still attach the qdisc to this entity, right? What prevents the
>> same functionality as with the "split"?
>
>The same problem we have with the VF TX rate. We only have Qdisc APIs
>for the TX direction. If we only have one port its TX is the TX onto
>wire. If we split it into MAC/phys and PCIe - the TX of PCI is the RX
>of the host, allowing us to control queuing on the PCIe interface.

I see. But is it needed? I mean, this is for the "management pf" on the
local host. You don't put it into VM. You should only use it for
slowpath (like arps, OVS, etc). If you want to have traffic from
localhost that you need to rate limit, you can either create dynamic PF
or VF or SF for it.