From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:54
This series contains updates to i40e and i40evf only.
Sridhar enables creation of a VF port Representor/Control netdev
associated with each VF, which allows control and configuring VFs from
Pfs namespace. Then enables the VF specific ethtool statistics via the
VF port Representor. Adds initial devlink support to set/get the mode
of a SRIOV switch. Fixes link state event handling by updating the
carrier and starts/stops the Tx queues based on the link state
notification from PF.
Brady fixes an issue where a user defined RSS hash key was not being
set because a user defined indirection table is not supplied when changing
the hash key, so if an indirection table is not supplied now, then a
default one is created and the hash key is correctly set. Also fixed
an issue where when NPAR was enabled, we were still using pf->mac_seid
to perform the dump port query. Instead, go through the VSI to determine
the correct ID to use in either case.
Mitch provides one fix where a conditional return code was reversed, so
he does a "switheroo" to fix the issue.
Carolyn has two fixes, first fixes an issue in the virt channel code,
where a return code was not checked for NULL when applicable. Second,
fixes an issue where we were byte swapping the port parameter, then
byte swapping it again in function execution.
Colin Ian King fixes a potential NULL pointer dereference.
Amritha adds support for switchdev ops on the VF port representors and
the PF uplink.
Bimmy changes up i40evf_up_complete() to be void since it always returns
success anyways, which allows cleaning up of code which checked the
return code from this function.
Alex fixed an issue where the driver was incorrectly assuming that we
would always be pulling no more than 1 descriptor from each fragment.
So to correct this, we just need to make certain to test all the way to
the end of the fragments as it is possible for us to span 2 descriptors
in the block before us so we need to guarantee that even the last 6
descriptors have enough data to fill a full frame.
The following are changes since commit 5737f6c92681939e417579b421f81f035e57c582:
mlx4: add missed recycle opportunity for XDP_TX on TX failure
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Alan Brady (2):
i40e: fix setting user defined RSS hash key
i40e: fix "dump port" command when NPAR enabled
Alexander Duyck (1):
i40e: Limit TX descriptor count in cases where frag size is greater
than 16K
Amritha Nambiar (1):
i40e: Add support for switchdev API for Switch ID
Bimmy Pujari (1):
i40evf: remove unnecessary error checking against i40evf_up_complete
Carolyn Wyborny (2):
i40e: Fix to check for NULL
i40e: Fix for extra byte swap in tunnel setup
Colin Ian King (1):
i40e: avoid potential null pointer dereference when assigning len
Lihong Yang (1):
i40evf: remove unnecessary error checking against i40e_shutdown_adminq
Mitch Williams (1):
i40e: return correct opcode to VF
Sridhar Samudrala (5):
i40e: Introduce VF port representor/control netdevs
i40e: Enable VF specific ethtool statistics via VF Port representor
netdevs
i40e: Introduce devlink interface
i40evf: Fix link state event handling
i40e: Sync link state between VFs and VF Port representors(VFPR)
drivers/net/ethernet/intel/Kconfig | 1 +
drivers/net/ethernet/intel/i40e/i40e.h | 7 +
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 7 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 84 ++++++++-
drivers/net/ethernet/intel/i40e/i40e_main.c | 120 +++++++++++--
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 7 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 196 ++++++++++++++++++++-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 16 ++
drivers/net/ethernet/intel/i40evf/i40e_common.c | 3 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 7 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 18 +-
.../net/ethernet/intel/i40evf/i40evf_virtchnl.c | 10 +-
12 files changed, 428 insertions(+), 48 deletions(-)
--
2.7.4
@@ -3116,3 +3116,75 @@ void i40e_set_ethtool_ops(struct net_device *netdev){netdev->ethtool_ops=&i40e_ethtool_ops;}++/* As the VF Port representor(VFPR) represents the switch port corresponding+*toaVF,thetx_andrx_stringsareswappedtoindicatethattheframes+*transmittedfromVFarereceivedonVFPRandtheframesreceivedonVFare+*transmittedfromVFPR.+*/+staticconstchari40e_vf_netdev_ethtool_sset[][ETH_GSTRING_LEN]={+"tx_bytes",+"tx_unicast",+"tx_multicast",+"tx_broadcast",+"tx_discards",+"tx_errors",+"rx_bytes",+"rx_unicast",+"rx_multicast",+"rx_broadcast",+"rx_discards",+"rx_unknown_protocol",+};++#define I40E_VF_NETDEV_ETHTOOL_STAT_COUNT \+ARRAY_SIZE(i40e_vf_netdev_ethtool_sset)++staticvoidi40e_vf_netdev_ethtool_get_strings(structnet_device*dev,+u32stringset,+u8*ethtool_strings)+{+switch(stringset){+caseETH_SS_STATS:+memcpy(ethtool_strings,&i40e_vf_netdev_ethtool_sset,+sizeof(i40e_vf_netdev_ethtool_sset));+break;+}+}++staticinti40e_vf_netdev_ethtool_get_sset_count(structnet_device*dev,+intstringset)+{+switch(stringset){+caseETH_SS_STATS:+returnI40E_VF_NETDEV_ETHTOOL_STAT_COUNT;+default:+return-EOPNOTSUPP;+}+}++staticvoidi40e_vf_netdev_ethtool_get_stats(structnet_device*dev,+structethtool_stats*target_ethtool_stats,+u64*target_stat_values)+{+structi40e_vf_netdev_priv*priv=netdev_priv(dev);+structi40e_vf*vf=priv->vf;+structi40e_pf*pf=vf->pf;+structi40e_vsi*vsi;++vsi=pf->vsi[vf->lan_vsi_idx];+i40e_update_stats(vsi);+memcpy(target_stat_values,&vsi->eth_stats,+I40E_VF_NETDEV_ETHTOOL_STAT_COUNT*8);+}++staticconststructethtool_opsi40e_vf_netdev_ethtool_ops={+.get_strings=i40e_vf_netdev_ethtool_get_strings,+.get_ethtool_stats=i40e_vf_netdev_ethtool_get_stats,+.get_sset_count=i40e_vf_netdev_ethtool_get_sset_count,+};++voidi40e_set_vf_netdev_ethtool_ops(structnet_device*netdev)+{+netdev->ethtool_ops=&i40e_vf_netdev_ethtool_ops;+}
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:55
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.
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip l show
297: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
299: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
300: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 88 ++++++++++++++++++++++
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 14 ++++
2 files changed, 102 insertions(+)
@@ -1003,6 +1003,90 @@ complete_reset:clear_bit(__I40E_VF_DISABLE,&pf->state);}+staticinti40e_vf_netdev_open(structnet_device*dev)+{+return0;+}++staticinti40e_vf_netdev_stop(structnet_device*dev)+{+return0;+}++staticconststructnet_device_opsi40e_vf_netdev_ops={+.ndo_open=i40e_vf_netdev_open,+.ndo_stop=i40e_vf_netdev_stop,+};++/**+*i40e_alloc_vf_netdev+*@vf:pointertotheVFstructure+*@vf_num:VFnumber+*+*CreateVFrepresentor/controlnetdev+**/+inti40e_alloc_vf_netdev(structi40e_vf*vf,u16vf_num)+{+structi40e_pf*pf=vf->pf;+structi40e_vsi*vsi=pf->vsi[pf->lan_vsi];+structi40e_vf_netdev_priv*priv;+charnetdev_name[IFNAMSIZ];+structnet_device*netdev;+interr;++snprintf(netdev_name,IFNAMSIZ,"%s-vf%d",vsi->netdev->name,vf_num);+netdev=alloc_netdev(sizeof(structi40e_vf_netdev_priv),netdev_name,+NET_NAME_UNKNOWN,ether_setup);+if(!netdev){+dev_err(&pf->pdev->dev,"alloc_netdev failed for vf:%d\n",+vf_num);+return-ENOMEM;+}++pf->vf[vf_num].ctrl_netdev=netdev;++priv=netdev_priv(netdev);+priv->vf=&(pf->vf[vf_num]);++netdev->netdev_ops=&i40e_vf_netdev_ops;++netif_carrier_off(netdev);+netif_tx_disable(netdev);++err=register_netdev(netdev);+if(err){+dev_err(&pf->pdev->dev,"register_netdev failed for vf: %s\n",+vf->ctrl_netdev->name);+free_netdev(netdev);+returnerr;+}++dev_info(&pf->pdev->dev,"VF representor(%s) created for VF %d\n",+vf->ctrl_netdev->name,vf_num);++return0;+}++/**+*i40e_free_vf_netdev+*@vf:pointertotheVFstructure+*+*FreeVFrepresentor/controlnetdev+**/+voidi40e_free_vf_netdev(structi40e_vf*vf)+{+structi40e_pf*pf=vf->pf;++if(!vf->ctrl_netdev)+return;++dev_info(&pf->pdev->dev,"Freeing VF representor(%s)\n",+vf->ctrl_netdev->name);++unregister_netdev(vf->ctrl_netdev);+free_netdev(vf->ctrl_netdev);+}+/***i40e_free_vfs*@pf:pointertothePFstructure
@@ -72,10 +72,21 @@ enum i40e_vf_capabilities {I40E_VIRTCHNL_VF_CAP_IWARP,};+/* VF Ctrl netdev private structure */+structi40e_vf_netdev_priv{+structi40e_vf*vf;+};+/* VF information structure */structi40e_vf{structi40e_pf*pf;+/* VF Port representor netdev that allows control and configuration+*ofVFsfromthehost.EnablesreturningVFstats,configuringlink+*state,mtu,fdb/vlansetc.+*/+structnet_device*ctrl_netdev;+/* VF id in the PF space */s16vf_id;/* all VF vsis connect to the same parent */
@@ -142,4 +153,7 @@ int i40e_ndo_set_vf_spoofchk(struct net_device *netdev, int vf_id, bool enable);voidi40e_vc_notify_link_state(structi40e_pf*pf);voidi40e_vc_notify_reset(structi40e_pf*pf);+inti40e_alloc_vf_netdev(structi40e_vf*vf,u16vf_num);+voidi40e_free_vf_netdev(structi40e_vf*vf);+#endif /* _I40E_VIRTCHNL_PF_H_ */
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:56
From: Alan Brady <redacted>
Previously, when using ethtool to change the RSS hash key, ethtool would
report back saying the old key was still being used and no error was
reported. It was unclear whether it was being reported incorrectly or
being set incorrectly. Debugging revealed 'i40e_set_rxfh()' returned
zero immediately instead of setting the key because a user defined
indirection table is not supplied when changing the hash key.
This fix instead changes it such that if an indirection table is not
supplied, then a default one is created and the hash key is now
correctly set.
Change-ID: Iddb621897ecf208650272b7ee46702cad7b69a71
Signed-off-by: Alan Brady <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e.h | 2 ++
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 12 +++++++-----
drivers/net/ethernet/intel/i40e/i40e_main.c | 6 ++----
3 files changed, 11 insertions(+), 9 deletions(-)
@@ -2948,8 +2946,12 @@ static int i40e_set_rxfh(struct net_device *netdev, const u32 *indir,}/* Each 32 bits pointed by 'indir' is stored with a lut entry */-for(i=0;i<I40E_HLUT_ARRAY_SIZE;i++)-vsi->rss_lut_user[i]=(u8)(indir[i]);+if(indir)+for(i=0;i<I40E_HLUT_ARRAY_SIZE;i++)+vsi->rss_lut_user[i]=(u8)(indir[i]);+else+i40e_fill_rss_lut(pf,vsi->rss_lut_user,I40E_HLUT_ARRAY_SIZE,+vsi->rss_size);returni40e_config_rss(vsi,seed,vsi->rss_lut_user,I40E_HLUT_ARRAY_SIZE);
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:56
From: Sridhar Samudrala <sridhar.samudrala@intel.com>
Add initial devlink support to set/get the mode of SRIOV switch.
By default the switch mode is set to 'switchdev' as VF Port representors
are created by default.
This patch allows the mode to be set to 'legacy' to disable creation of
VF Port representor netdevs.
With smode support in iproute2 'devlink' utility, switch mode can be set
and get via following commands.
# devlink dev smode pci/0000:05:00.0
mode: switchdev
# devlink dev set pci/0000:05:00.0 smode legacy
# devlink dev smode pci/0000:05:00.0
mode: legacy
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/Kconfig | 1 +
drivers/net/ethernet/intel/i40e/i40e.h | 3 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 91 ++++++++++++++++++++--
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 6 +-
4 files changed, 91 insertions(+), 10 deletions(-)
@@ -10770,20 +10833,28 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)pci_enable_pcie_error_reporting(pdev);pci_set_master(pdev);+devlink=devlink_alloc(&i40e_devlink_ops,sizeof(*pf));+if(!devlink){+dev_err(&pdev->dev,"devlink_alloc failed\n");+err=-ENOMEM;+gotoerr_devlink_alloc;+}+/* Now that we have a PCI connection, we need to do the*lowleveldevicesetup.Thisisprimarilysettingup*theAdminQueuestructuresandthenqueryingforthe*device'scurrentprofileinformation.*/-pf=kzalloc(sizeof(*pf),GFP_KERNEL);-if(!pf){-err=-ENOMEM;-gotoerr_pf_alloc;-}+pf=devlink_priv(devlink);pf->next_vsi=0;pf->pdev=pdev;set_bit(__I40E_DOWN,&pf->state);+pf->eswitch_mode=DEVLINK_ESWITCH_MODE_SWITCHDEV;+err=devlink_register(devlink,&pdev->dev);+if(err)+gotoerr_devlink_register;+hw=&pf->hw;hw->back=pf;
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:57
From: Carolyn Wyborny <redacted>
This patch fixes an issue where we were byte swapping the port
parameter, then byte swapping it again in function execution.
Obviously, that's unnecessary, so take it out of the function calls.
Without this patch, the udp based tunnel configuration would
not be correct.
Change-ID: I788d83c5bd5732170f1a81dbfa0b1ac3ca8ea5b7
Signed-off-by: Carolyn Wyborny <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:57
From: Alan Brady <redacted>
When using the debugfs to issue the "dump port" command
with NPAR enabled, the firmware reports back with invalid argument.
The issue occurs because the pf->mac_seid was used to perform the query.
This is fine when NPAR is disabled because the switch ID == pf->mac_seid,
however this is not the case when NPAR is enabled. This fix instead
goes through the VSI to determine the correct ID to use in either case.
Change-ID: I0cd67913a7f2c4a2962e06d39e32e7447cc55b6a
Signed-off-by: Alan Brady <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:57
From: Carolyn Wyborny <redacted>
This patch fixes an issue in the virt channel code, where a return
from i40e_find_vsi_from_id was not checked for NULL when applicable.
Without this patch, there is a risk for panic and static analysis
tools complain. This patch fixes the problem by adding the check
and adding an additional input check for similar reasons.
Change-ID: I7e9be88eb7a3addb50eadc451c8336d9e06f5394
Signed-off-by: Carolyn Wyborny <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:57
From: Mitch Williams <redacted>
This conditional is backward, so the driver responds back to the VF with
the wrong opcode. Do the old switcheroo to fix this.
Change-ID: I384035b0fef8a3881c176de4b4672009b3400b25
Signed-off-by: Mitch Williams <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -2308,8 +2308,8 @@ static int i40e_vc_iwarp_qvmap_msg(struct i40e_vf *vf, u8 *msg, u16 msglen,error_param:/* send the response to the VF */returni40e_vc_send_resp_to_vf(vf,-config?I40E_VIRTCHNL_OP_RELEASE_IWARP_IRQ_MAP:-I40E_VIRTCHNL_OP_CONFIG_IWARP_IRQ_MAP,+config?I40E_VIRTCHNL_OP_CONFIG_IWARP_IRQ_MAP:+I40E_VIRTCHNL_OP_RELEASE_IWARP_IRQ_MAP,aq_ret);}
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:58
From: Colin Ian King <redacted>
There is a sanitcy check for desc being null in the first line of
function i40evf_debug_aq. However, before that, aq_desc is cast from
desc, and aq_desc is being dereferenced on the assignment of len, so
this could be a potential null pointer deference. Fix this by moving
the initialization of len to the code block where len is being used
and hence at this point we know it is OK to dereference aq_desc.
Signed-off-by: Colin Ian King <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40evf/i40e_common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:58
From: Sridhar Samudrala <sridhar.samudrala@intel.com>
Currently disabling the link state from PF via
ip link set enp5s0f0 vf 0 state disable
doesn't disable the CARRIER on the VF.
This patch updates the carrier and starts/stops the tx queues based on the
link state notification from PF.
PF: enp5s0f0, VF: enp5s2
#modprobe i40e
#echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
#ip link set enp5s2 up
#ip -d link show enp5s2
175: enp5s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64
#ip link set enp5s0f0 vf 0 state disable
#ip -d link show enp5s0f0
171: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 72 numrxqueues 72 portid 6805ca2e7268
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state disable, trust off
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
#ip -d link show enp5s2
175: enp5s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 16 numrxqueues 16
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 4 ++++
drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 10 +++++++---
2 files changed, 11 insertions(+), 3 deletions(-)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:58
From: Amritha Nambiar <redacted>
This patch adds support for switchdev ops on the VF Port representors
and the PF uplink, the only operation implemented is the port attribute
API to get the port parent ID or the switch ID. The switch ID is used
to identify the net_devices attached to the same HW switch.
The switch ID returned for the VF Port representors and the PF uplink
is the phys_port_id.
102: enp9s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 68:05:ca:35:77:50 brd ff:ff:ff:ff:ff:ff promiscuity 0 numtxqueues 64 numrxqueues 64 portid 6805ca357750 switchid 6805ca357750
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
103: enp9s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 68:05:ca:35:77:51 brd ff:ff:ff:ff:ff:ff promiscuity 0 numtxqueues 64 numrxqueues 64 portid 6805ca357751 switchid 6805ca357751
104: enp9s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff promiscuity 0 numtxqueues 1 numrxqueues 1 switchid 6805ca357750
105: enp9s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff promiscuity 0 numtxqueues 1 numrxqueues 1 switchid 6805ca357750
inet6 fe80::200:ff:fe00:0/64 scope link tentative
valid_lft forever preferred_lft forever
Signed-off-by: Amritha Nambiar <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 17 +++++++
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 57 ++++++++++++++++++++++
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 2 +
4 files changed, 77 insertions(+)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:59
From: Sridhar Samudrala <sridhar.samudrala@intel.com>
This patch enables
- reflecting the link state of VFPR based on VF admin state & link state
of VF based on admin state of VFPR.
- bringing up/down the VFPR sends a notification to update VF link state.
- bringing up/down the VF will cause the link state update of VFPR.
- enable/disable VF link state via ndo_set_vf_link_state will update the
admin state of associated VFPR.
PF: enp5s0f0, VFs: enp5s2,enp5s2f1 VFPRs:enp5s0f0-vf0, enp5s0f0-vf1
# modprobe i40e
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip link set enp5s2 up
# ip link set enp5s0f0-vf0 up
# ip link set enp5s0f0-vf1 up
# ip link show enp5s0f0-vf0
215: enp5s0f0-vf0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
/* enp5s0f0-vf0 UP -> enp5s2 CARRIER ON */
# ip link show enp5s2
218: enp5s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff
/* enp5s2f1 DOWN -> enp5s0f0-vf1 NO-CARRIER */
# ip link show enp5s0f0-vf1
216: enp5s0f0-vf1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# ip link set enp5s0f0-vf0 down
# ip link set enp5s2f1 up
/* enp5s2 UP -> enp5s0f0-vf1 CARRIER ON */
# ip link show enp5s0f0-vf1
216: enp5s0f0-vf1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
/* enp5s0-vf0 DOWN -> enp5s2 NO_CARRIER */
# ip link show enp5s2
218: enp5s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff
# ip -d link show enp5s0f0
213: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state disable
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state enable
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
@@ -1907,6 +1921,10 @@ static int i40e_vc_enable_queues_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)if(i40e_vsi_control_rings(pf->vsi[vf->lan_vsi_idx],true))aq_ret=I40E_ERR_TIMEOUT;++if((0==aq_ret)&&vf->ctrl_netdev)+netif_carrier_on(vf->ctrl_netdev);+error_param:/* send the response to the VF */returni40e_vc_send_resp_to_vf(vf,I40E_VIRTCHNL_OP_ENABLE_QUEUES,
@@ -1947,6 +1965,9 @@ static int i40e_vc_disable_queues_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)if(i40e_vsi_control_rings(pf->vsi[vf->lan_vsi_idx],false))aq_ret=I40E_ERR_TIMEOUT;+if((0==aq_ret)&&vf->ctrl_netdev)+netif_carrier_off(vf->ctrl_netdev);+error_param:/* send the response to the VF */returni40e_vc_send_resp_to_vf(vf,I40E_VIRTCHNL_OP_DISABLE_QUEUES,
@@ -3179,6 +3200,7 @@ int i40e_ndo_set_vf_link_state(struct net_device *netdev, int vf_id, int link)structi40e_virtchnl_pf_eventpfe;structi40e_hw*hw=&pf->hw;structi40e_vf*vf;+structnet_device*vf_netdev;intabs_vf_id;intret=0;
@@ -3219,6 +3241,17 @@ int i40e_ndo_set_vf_link_state(struct net_device *netdev, int vf_id, int link)ret=-EINVAL;gotoerror_out;}++vf_netdev=vf->ctrl_netdev;+if(vf_netdev){+unsignedintflags=vf_netdev->flags;++if(vf->link_up)+dev_change_flags(vf_netdev,flags|IFF_UP);+else+dev_change_flags(vf_netdev,flags&~IFF_UP);+}+/* Notify the VF of its new link state */i40e_aq_send_msg_to_vf(hw,abs_vf_id,I40E_VIRTCHNL_OP_EVENT,0,(u8*)&pfe,sizeof(pfe),NULL);
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:59
From: Bimmy Pujari <redacted>
Function i40evf_up_complete() always returns success. Changed this to a
void type and removed the code that checks the return status and prints
an error message.
Change-ID: I8c400f174786b9c855f679e470f35af292fb50ad
Signed-off-by: Bimmy Pujari <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:43:59
From: Alexander Duyck <redacted>
The i40e driver was incorrectly assuming that we would always be pulling
no more than 1 descriptor from each fragment. It is in fact possible for
us to end up with the case where 2 descriptors worth of data may be pulled
when a frame is larger than one of the pieces generated when aligning the
payload to either 4K or pieces smaller than 16K.
To adjust for this we just need to make certain to test all the way to the
end of the fragments as it is possible for us to span 2 descriptors in the
block before us so we need to guarantee that even the last 6 descriptors
have enough data to fill a full frame.
Change-ID: Ic2ecb4d6b745f447d334e66c14002152f50e2f99
Signed-off-by: Alexander Duyck <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 7 ++-----
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 7 ++-----
2 files changed, 4 insertions(+), 10 deletions(-)
@@ -2621,9 +2621,7 @@ bool __i40e_chk_linearize(struct sk_buff *skb)returnfalse;/* We need to walk through the list and validate that each group-*of6fragmentstotalsatleastgso_size.Howeverwedon'tneed-*toperformsuchvalidationonthelast6sincethelast6cannot-*inheritanydatafromadescriptorafterthem.+*of6fragmentstotalsatleastgso_size.*/nr_frags-=I40E_MAX_BUFFER_TXD-2;frag=&skb_shinfo(skb)->frags[0];
@@ -2654,8 +2652,7 @@ bool __i40e_chk_linearize(struct sk_buff *skb)if(sum<0)returntrue;-/* use pre-decrement to avoid processing last fragment */-if(!--nr_frags)+if(!nr_frags--)break;sum-=skb_frag_size(stale++);
@@ -1832,9 +1832,7 @@ bool __i40evf_chk_linearize(struct sk_buff *skb)returnfalse;/* We need to walk through the list and validate that each group-*of6fragmentstotalsatleastgso_size.Howeverwedon'tneed-*toperformsuchvalidationonthelast6sincethelast6cannot-*inheritanydatafromadescriptorafterthem.+*of6fragmentstotalsatleastgso_size.*/nr_frags-=I40E_MAX_BUFFER_TXD-2;frag=&skb_shinfo(skb)->frags[0];
@@ -1865,8 +1863,7 @@ bool __i40evf_chk_linearize(struct sk_buff *skb)if(sum<0)returntrue;-/* use pre-decrement to avoid processing last fragment */-if(!--nr_frags)+if(!nr_frags--)break;sum-=skb_frag_size(stale++);
From: Jeff Kirsher <hidden> Date: 2016-09-21 03:44:00
From: Lihong Yang <redacted>
The i40e_shutdown_adminq function never returns failure. There is no need to
check the non-0 return value. Clean up the unnecessary error checking and
warning against it.
Change-ID: Ibb616f09cfb93bd1a872ebf3241a15fb8354b31b
Signed-off-by: Lihong Yang <redacted>
Tested-by: Andrew Bowers <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
@@ -1785,8 +1785,7 @@ continue_reset:i40evf_free_all_tx_resources(adapter);/* kill and reinit the admin queue */-if(i40evf_shutdown_adminq(hw))-dev_warn(&adapter->pdev->dev,"Failed to shut down adminq\n");+i40evf_shutdown_adminq(hw);adapter->current_op=I40E_VIRTCHNL_OP_UNKNOWN;err=i40evf_init_adminq(hw);if(err)
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?
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)?
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.
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.
Or
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip l show
297: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
299: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
300: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
From: Or Gerlitz <hidden> Date: 2016-09-21 04:26:24
On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
[off-list ref] wrote:
From: Sridhar Samudrala <sridhar.samudrala@intel.com>
Sample script that shows ethtool stats on VF representor netdev
PF: enp5s0f0, VF0: enp5s2 VF_REP0: enp5s0f0-vf0
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip link set enp5s2 up
# ethtool -S enp5s0f0-vf0
NIC statistics:
tx_bytes: 0
tx_unicast: 0
tx_multicast: 0
tx_broadcast: 0
tx_discards: 0
tx_errors: 0
rx_bytes: 140
rx_unicast: 0
rx_multicast: 2
rx_broadcast: 0
rx_discards: 0
rx_unknown_protocol: 0
Now, when the SW stats are finally upstream for 4.9 in net-next, the
correct approach
for the VF reps counters is to follow the architecture presented there
[1] -- and this is
for the netlink based standard counters. Once you do that, there's no
need to expose
the VF HW counters through ethtool of the VF rep.
Or.
[1] offloaded stats commits
a5ea31f Merge branch 'net-offloaded-stats'
fc1bbb0 mlxsw: spectrum: Implement offload stats ndo and expose HW
stats by default
69ae6ad net: core: Add offload stats to if_stats_msg
2c9d85d netdevice: Add offload statistics ndo
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.
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.
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.
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.
Or
quoted
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip l show
297: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid 6805ca2e7268 state DOWN mode DEFAULT group default qlen 1000
link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
299: enp5s0f0-vf0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
300: enp5s0f0-vf1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
On Wed, Sep 21, 2016 at 6:43 AM, Jeff Kirsher
[off-list ref] wrote:
quoted
From: Sridhar Samudrala <sridhar.samudrala@intel.com>
Sample script that shows ethtool stats on VF representor netdev
PF: enp5s0f0, VF0: enp5s2 VF_REP0: enp5s0f0-vf0
# echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
# ip link set enp5s2 up
# ethtool -S enp5s0f0-vf0
NIC statistics:
tx_bytes: 0
tx_unicast: 0
tx_multicast: 0
tx_broadcast: 0
tx_discards: 0
tx_errors: 0
rx_bytes: 140
rx_unicast: 0
rx_multicast: 2
rx_broadcast: 0
rx_discards: 0
rx_unknown_protocol: 0
Now, when the SW stats are finally upstream for 4.9 in net-next, the
correct approach
for the VF reps counters is to follow the architecture presented there
[1] -- and this is
for the netlink based standard counters. Once you do that, there's no
need to expose
the VF HW counters through ethtool of the VF rep.
Sure. Will look into it. However, i think we can keep ethtool support also as VFPR
represents the switch port corresponding to the VF.
From: Or Gerlitz <hidden> Date: 2016-09-21 06:54:49
On Wed, Sep 21, 2016 at 8:59 AM, Samudrala, Sridhar
[off-list ref] wrote:
On 9/20/2016 9:26 PM, Or Gerlitz wrote:
quoted
Now, when the SW stats are finally upstream for 4.9 in net-next, the
correct approach
for the VF reps counters is to follow the architecture presented there
[1] -- and this is
for the netlink based standard counters. Once you do that, there's no
need to expose
the VF HW counters through ethtool of the VF rep.
Sure. Will look into it. However, i think we can keep ethtool support also
as VFPR represents the switch port corresponding to the VF.
Exactly b/c the VFPR represented the VF switch port, their "normal" stats
is what you are exposing here through ethtool, you can just drop this and
move to the strategy introduced in Nogah's work. Once you support TX/RX
on the VFPRs you can also add the SW stats she added too.
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.
On Wed, Sep 21, 2016 at 8:45 AM, Samudrala, Sridhar
[off-list ref] wrote:
quoted
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
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
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.
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...
The VF driver requests adding the dmac based filter rules via mailbox messages to PF and that is
not changed in this patchset.
Once we have VFPR TX/RX support, we will not allow the VF driver to add these rules, Instead a host based
program will be able to add these rules to enable the fast path.
Thanks
Sridhar
From: Or Gerlitz <hidden> Date: 2016-09-21 19:21:20
On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
[off-list ref] wrote:
On 9/21/2016 12:04 AM, Or Gerlitz wrote:
quoted
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...
The VF driver requests adding the dmac based filter rules via mailbox
messages to PF and that is not changed in this patchset.
Once we have VFPR TX/RX support, we will not allow the VF driver to add
these rules, Instead a host based
program will be able to add these rules to enable the fast path.
I see, this means that when this patch set is applied your driver
reports through devlink that they are in switchdev mode, but the
operational state of the VFs and VFPRs isn't such - as the VFs dictate
the steering and the VFPRs don't support slow path TX/RX --- in an
earlier comment you made on this thread you said that you will be
submitting RX/TX support in the next patchset. Maybe it would be best
if you can take the VFPRs patches out of this series and roll a follow
up series with all what's needed? unless you need more time and gonna
miss 4.9 as of that... if the patches are ready, I say lets have them
all in one series, if not, I wonder what other people think on the
matter. I am basically half+ good to have also the half baked code
base merged
Anyway, there's no point to report through ethtool something (VF vport
HW stats) you can report in the standard and convenient manner, so
this one please do address regardless of the prev comment.
Or.
From: Jeff Kirsher <hidden> Date: 2016-09-21 21:23:30
On Wed, 2016-09-21 at 22:21 +0300, Or Gerlitz wrote:
On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
[off-list ref] wrote:
quoted
On 9/21/2016 12:04 AM, Or Gerlitz wrote:
quoted
quoted
so what happens after this patchset is applied and before the future
work is
quoted
quoted
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
quoted
quoted
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...
quoted
The VF driver requests adding the dmac based filter rules via mailbox
messages to PF and that is not changed in this patchset.
Once we have VFPR TX/RX support, we will not allow the VF driver to add
these rules, Instead a host based
program will be able to add these rules to enable the fast path.
I see, this means that when this patch set is applied your driver
reports through devlink that they are in switchdev mode, but the
operational state of the VFs and VFPRs isn't such - as the VFs dictate
the steering and the VFPRs don't support slow path TX/RX --- in an
earlier comment you made on this thread you said that you will be
submitting RX/TX support in the next patchset. Maybe it would be best
if you can take the VFPRs patches out of this series and roll a follow
up series with all what's needed? unless you need more time and gonna
miss 4.9 as of that... if the patches are ready, I say lets have them
all in one series, if not, I wonder what other people think on the
matter. I am basically half+ good to have also the half baked code
base merged
Anyway, there's no point to report through ethtool something (VF vport
HW stats) you can report in the standard and convenient manner, so
this one please do address regardless of the prev comment.
I will drop Sridhar's changes from this series for now, so that he can do
the re-work AND provide the additional patches he referred to earlier at a
later date.