[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <586693A6.5090105@intel.com>
Date: Fri, 30 Dec 2016 09:04:38 -0800
From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To: Or Gerlitz <gerlitz.or@...il.com>
CC: Alexander Duyck <alexander.h.duyck@...el.com>,
John Fastabend <john.r.fastabend@...el.com>,
Anjali Singhai Jain <anjali.singhai@...el.com>,
jakub.kicinski@...ronome.com, intel-wired-lan@...ts.osuosl.org,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [net-next PATCH 5/6] i40e: Add TX and RX support in switchdev
mode.
On 12/30/2016 7:31 AM, Or Gerlitz wrote:
> On Fri, Dec 30, 2016 at 8:21 AM, Sridhar Samudrala
> <sridhar.samudrala@...el.com> wrote:
>> In switchdev mode, broadcast filter is not enabled on VFs, The broadcasts and
> nit ", The broadcast" --> ", the broadcasts" or ". The broadcasts"
>
>> unknown frames from VFs are received by the PF and passed to corresponding VF
>> port representator netdev.
>> A host based switching entity like a linux bridge or OVS redirects these frames
>> to the right VFs via VFPR netdevs. Any frames sent via VFPR netdevs are sent as
>> directed transmits to the corresponding VFs. To enable directed transmit, skb
>> metadata dst is used to pass the VF id and the frame is requeued to call the PFs
>> transmit routine.
> So the representator netdevs do or don't have TX/RX rings of their
> own? if the latter, was there any special locking you had to do for
> that?
Atleast in the inital implementation, we are not creating any TX/RX
rings for VFPR netdevs.
skb->dev is set to the PF device and skb is requeued via dev_queue_xmit().
>
> Are you exposing switchdev ops for the representators? didn't see that
> or maybe it's in the 4th patch which didn't make it to the list?
Not at this time. In the future patches when we offload fdb/vlan
functionality, we could use
switchdev ops.
Powered by blists - more mailing lists