Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs
flat view
From: Or Gerlitz <hidden>
Date: 2016-09-21 07:04:30
On Wed, Sep 21, 2016 at 8:45 AM, Samudrala, Sridhar [off-list ref] wrote:
On 9/20/2016 9:22 PM, Or Gerlitz wrote:quoted
On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher [off-list ref] wrote:quoted
From: Sridhar Samudrala <sridhar.samudrala@intel.com> This patch enables creation of a VF Port representor/Control netdev associated with each VF. These netdevs can be used to control and configure VFs from PFs namespace. They enable exposing VF statistics, configuring link state, mtu, fdb/vlan entries etc.What happens if someone does a xmit on the VF representor, does the packet show up @ the VF? and what happens of the VF xmits and there's no HW steering rule that matches this, does the frame show up @ the VF rep on the host?
TX/RX are not yet supported via VFPR netdevs in this patch series. Will be submitting this support in the next patchset.
Okay, good.
quoted
In other words, can these VF reps serve for setting up host SW based switching which you can later offload (through TC, bridge, netfilter, etc)?
Yes. These offloads will be possible via VFPRs.
cool
quoted
I am posing these questions because in downstream patch you are adding devlink support for set/get the e-switch mode and you declare the default mode to be switchdev.
quoted
When the switchdev mode was introduced in 4.8 these RX/TX characteristics were defined to be an essential (== requirement) part for a driver to support that mode.
The current patchset introduces the basic VFPR support starting with exposing VF stats and syncing link state between VFs and VFPRs. We decided to declare the default mode to be switchdev so that the new code paths will get exercised by default during normal testing.
so what happens after this patchset is applied and before the future work is submitted? RX/TX slow path through the VFPRs isn't supported and what about fast path? in other words what happens when someone loads the driver, sets SRIOV (--> the driver set itself to switchdev mode and VFPRs are created) and then a VF sends a packet? do you still put into the HW the legacy DMAC based switching rules? I am not following... Or.