Date:   Tue, 4 Apr 2017 08:29:03 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Or Gerlitz <gerlitz.or@...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 4:58 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> On Mon, Apr 3, 2017 at 9:41 PM, Samudrala, Sridhar
> <sridhar.samudrala@...el.com> wrote:
>> On 3/30/2017 12:17 AM, Or Gerlitz wrote:
>>> On Thu, Mar 30, 2017, Sridhar Samudrala wrote:
>
>>>> Port Representator netdevs are created for each PF and VF if the switch
>>>> mode is set to 'switchdev'. These netdevs can be used to control and
>>>> configure VFs and PFs when they are moved to a different namespace.
>>>> They enable exposing statistics, configure and monitor link state, mtu,
>>>> filters,fdb/vlan entries etc.
>
>>>> In switchdev mode, broadcasts from VFs are received by the PF and passed
>>>> to corresponding port representor netdev.
>
>>> What netdev represents the uplink (wire port) in your impl?
>
> combining your replies from the two emails:
>
>> We don't have a port netdev representing the uplink in this implementation as we
>> cannot control the frames going out the uplink via sw rules with the current
>> generation of hw/fw.
>
>> fwd to CPU as default rule is not possible with the current generation of hw/fw.
>> So we would like to enable switchdev to expose the port representors and start
>> adding offloads in an incremental way.
>
> I lost you even deeper
>
> 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?

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.

> 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.

> If your current HW can't let you have "send to CPU" as the default
> action on ingress
> for the VFs and uplink ports, I am not clear what use-cases you can do
> in slow path
> (only reps, no offloaded SW rules) and for past path (reps + offloaded
> SW rules)...
>
> 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. 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.

- Alex

Powered by blists - more mailing lists