netdev - Re: [PATCH net-next v2 0/3] VGT+ support

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 13 Nov 2019 22:55:16 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>
CC:     "sbrivio@...hat.com" <sbrivio@...hat.com>,
        "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
        "dsahern@...il.com" <dsahern@...il.com>,
        "sd@...asysnail.net" <sd@...asysnail.net>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "lariel@...lanox.com" <lariel@...lanox.com>
Subject: Re: [PATCH net-next v2 0/3] VGT+ support

Hi Jakub,

On Tue, 2019-11-05 at 17:38 -0800, Jakub Kicinski wrote:
> In the upstream community, however, we care about the technical
> aspects.
> 
> > and we all know that it could take years before we can sit back and
> > relax that we got our L2 switching .. 
> 
> Let's not be dramatic. It shouldn't take years to implement basic L2
> switching offload.

I had meant to send something earlier in this thread, but never got
around to it. I wanted to ask your opinion and get some feedback.

We (Intel) have recently been investigating use of port representors
for enabling introspection and control of VFs in the host system after
they've been assigned to a virtual machine.

I had originally been thinking of adding these port representor netdevs
before we fully implement switchdev with the e-switch offloads. The
idea was to migrate to using port representors in either case.

However, from what it looks like on this thread, you'd rather propose
that we implement switchdev with basic L2 offload?

I'm not too familiar with switchdev, (trying to read and learn about so
that we can begin actually implementing it in our network drivers).

Based on your comments and feedback in this thread, it sounds like our
original idea to have a "legacy with port representors" mode is not
really something you'd like, because it would continue to encourage
avoiding migrating from legacy stack to switchdev model.

But, instead of trying to go fully towards implementing switchdev with
complicated OvS offloads, we could do a simpler approach that only
supports L2 offloads initially, and from these comments it seems this
is the direction you'd rather upstream persue?

> I had given switchdev L2 some thought. IDK what you'd call serious, 
> I don't have code. We are doing some ridiculously complex OvS
> offloads
> while most customers just need L2 plus maybe VXLAN encap and basic
> ACLs. Which switchdev can do very nicely thanks to Cumulus folks.

Based on this, it sounds like the switchdev API can do this L2
offloading and drivers simply need to enable it. If I understand
correctly, it  requires the system administrator to place the VF devies
into a bridge, rather than simply having the bridging hidden inside the
device.

Thanks,
Jake