netdev - Re: [Intel-wired-lan] [next-queue v6 PATCH 2/7] i40e: Introduce Port Representor netdevs and switchdev mode.

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] [day] [month] [year] [list]

Date:   Wed, 5 Apr 2017 16:41:34 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        intel-wired-lan <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [Intel-wired-lan] [next-queue v6 PATCH 2/7] i40e: Introduce Port
 Representor netdevs and switchdev mode.

On Tue, Apr 4, 2017 at 6:29 PM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Tue, Apr 4, 2017 at 4:58 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:

>> I was asking on frames getting in from the uplink and not getting out
>> the uplink.

> Frames coming from the uplink will by default be routed to the PF. So
> are you saying you want a representor for the uplink to handle the
> packets that don't have any rules set up for them, correct?

In our impl, currently the PF serves the uplink representor when we
are in the switchdev mode.

> I think we could set something like this up as we do have the concept
> of a "default" entity that everything falls back into. It is just a
> bit muddled since that current exists as a part of the PF.

>> This is about offloading to HW a switching model where the steering
>> (matching and actions) comes into play on the port ingress. E.g
>> VF NIC xmit ---> VF vport e-switch rep recv --> SW or HW steering

> So this bit we can't really support very well with the i40e hardware.
> The problem is that unless there is a rule that exists to route it to
> another PF/VF there is a default rule in the hardware that would send
> it out the uplink port. The only data we can really catch on the port
> representors is broadcast/multicast because it does replication.

Can't you put a black hole (matching on nothing) rule saying that if
source is VF send it to the PF RX queues and not to the wire, from
the PF recv descriptor somehow realize from what VF the packet originated
and then inject it to the host kernel as it was received from the rep
of that VF?

Later when you add offloads, you make this rule with the lowest prio.

>> other node xmit --> UPLINK vport e-switch rep recv --> SW or HW steering

> This part I think we can do. The default behavior would be to send a
> packet to the default entity which in this case is the PF.

good

>> Can you please elaborate on such use-cases, so the bigger picture is more clear?

> So the main goal with all of this is to support TC offloads so that we
> can program filters to route packets from the default entity to the VF.

This is somehow too limited and I don't see what use case it can serve :(

> I agree that I think we are missing the uplink port. We probably
> just need to add it as the "default" handler for packets that
> originate with a source MAC address that is not the PF or one of the VFs.

> We can discuss this further at netdev/netconf.

yeah, but I will not be there (still asked everyone to get me a pack
of maple cookies),
so feel free to discuss with the MLNX folks, Rony and Jiri

Or.