[dpdk-dev] Vlan not working with Mellanox NIC on VmWare

[Dey, Souvik]

Hi All,
We were trying to test the vlan filter with Melloanox 
nic(SR-IOV) on VmWare  using the mlx5_pmd. But found that after doing the 
mlx5_vlan_filter_set with the vlan id also, we are not receiving the tagged 
packets upto the application. The same works fine in we are using KVM as the 
hypervisor. To check if this the PF deiver issue, we removed the dpdk and made 
the vlan config on the linux interface and then found that the tagged packets 
are coming upto the VM. Moreover the same tag which was used by linux kernel 
keeps working with DPDK too even after reboot o the VM but new tags added 
through DPDK does not work . Is it necessary to add the tags every time to the 
linux netdev before using it through dpdk ? Though this does not sound 
right.Can somebody help me in why with dpdk we are not able to receive the 
tagged packets ?

DPDK version : 18.11.6
ESXi : 7.0
NICs : Mellanox Cx-4

Just to summarize :

  1.  VLAN filter add through DPDK works fine with KVM hypervisor.
  2.  VLAN filter add through DPDK on VmWare does not work.
  3.  VLAN add through linux netdev works fine on VmWare
  4.  VLAN once added on the linux netdev, even after eboot the same VLAN added 
through dpdk works fine on VmWare. Any new VLAN added through dpdk does not 
work.

--
Regards,
Souvik

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: [dpdk-dev] Not able to start IAVF PMD with dpdk 20.11.3

[Dey, Souvik]

Hi Wu, 
Thanks for the update. I got rid of the vfio-pci probe issue by enabling 
"modprobe vfio enable_unsafe_noiommu_mode=1". This was required as I am trying 
inside a VM where VT-d is not enabled. Now once I bind the interfaces( VF) to 
the vfio-pci instead of uio_pci_generic , the links are coming up fine and I am 
able to rx/tx packets out of the VF. Thanks once again for the quick help on 
this. 

Just one follow up question. Are we saying we cannot use uio_pci_generic  
module for the E810 VFs ? is it a bug, do we have any fixes for the same 
already upstreamed ? 

--
Regards,
Souvik

-Original Message-
From: dev  On Behalf Of Dey, Souvik
Sent: Friday, September 24, 2021 1:57 AM
To: Wu, Jingjing ; dev@dpdk.org; Xing, Beilei 

Subject: [EXTERNAL] Re: [dpdk-dev] Not able to start IAVF PMD with dpdk 20.11.3

With vfio_pci , I am getting the following error and bind itself is failing, 
due to probe fail with EINVAL.
[root@connexip swe]# ./dpdk-devbind.py -b vfio_pci 08:00.0
Error: bind failed for :08:00.0 - Cannot open 
/sys/bus/pci/drivers/vfio_pci/bind
Sep 24 01:50:29 connexip kernel: [  323.376403] vfio-pci: probe of :08:00.0 
failed with error -22 Sep 24 01:50:29 connexip kernel: [  323.376440] vfio-pci: 
probe of :08:00.0 failed with error -22

I am using kernel 4.19.194 from debian buster.

From: Wu, Jingjing 
Sent: Thursday, September 23, 2021 8:41 PM
To: Dey, Souvik ; dev@dpdk.org; Xing, Beilei 

Subject: [EXTERNAL] RE: Not able to start IAVF PMD with dpdk 20.11.3

Could you have a try to switch from  uio_pci_generic to vfio_pci?

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Thursday, September 23, 2021 11:29 PM
To: dev@dpdk.org<mailto:dev@dpdk.org>; Xing, Beilei 
mailto:beilei.x...@intel.com>>; Wu, Jingjing 
mailto:jingjing...@intel.com>>
Subject: Not able to start IAVF PMD with dpdk 20.11.3

Hi All,
 Trying to test E810 Sr-IOV based nic card with 20.11.3 dpdk. I am running 
the host kernel driver and only the VF is attached to the VM where I am running 
dpdk. But when I attaching the VF to the testpmd it is throwing the below 
error. Is there are way to move forward here ?

[root@connexip linuxadmin]# ./dpdk-testpmd -c 0xf -n 4 -a 08:00.0 -- -i 
--rxq=16 --txq=16
EAL: Detected 4 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: Probe PCI driver: net_iavf (8086:1889) device: :08:00.0 (socket 0)
EAL: Error reading from file descriptor 27: Input/output error
EAL: No legacy callbacks, legacy socket not created Interactive-mode selected
testpmd: create a new mbuf pool : n=171456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will 
pair with itself.

Configuring Port 0 (socket 0)
EAL: Error reading from file descriptor 27: Input/output error
iavf_execute_vf_cmd(): No response for cmd 28
iavf_disable_vlan_strip(): Failed to execute command of 
OP_DISABLE_VLAN_STRIPPING
iavf_execute_vf_cmd(): No response for cmd 24
iavf_configure_rss_lut(): Failed to execute command of OP_CONFIG_RSS_LUT
iavf_dev_configure(): configure rss failed
Port0 dev_configure = -1
Fail to configure port 0
EAL: Error - exiting with code: 1
  Cause: Start ports failed
[root@connexip linuxadmin]#


I do see the matching list for driver but is this required even if I use kernel 
driver on the host and only IAVF PMD on the guest ?

DPDK
Kernel Driver
OS Default DDP
COMMS DDP
Wireless DDP
Firmware
20.11
1.3.2
1.3.20
1.3.24
N/A
2.3
21.02
1.4.11
1.3.24
1.3.28
1.3.4
2.4



Host details:
Red Hat Enterprise Linux release 8.2 (Ootpa) [root@localhost ~]# modinfo ice
filename:   
/lib/modules/4.18.0-193.19.1.el8_2.x86_64/kernel/drivers/net/ethernet/intel/ice/ice.ko.xz
firmware:   intel/ice/ddp/ice.pkg (ice-1.3.4.0.pkg)
version:0.8.1-k
license:GPL v2
description:Intel(R) Ethernet Connection E800 Series Linux Driver
author: Intel Corporation, 
linux.n...@intel.com<mailto:linux.n...@intel.com>
rhelversion:8.2
Using vfio-pci to connect the VF to the VM.

Guest Details:
OS : debian buster
Dpdk : 20.11.3
Interface bound to uio_pci_generic
[root@connexip linuxadmin]# /opt/sonus/bin/np/swe/dpdk-devbind.py --status

Network devices using DPDK-compatible driver 

:01:00.0 'Virtio network device 1041' drv=uio_pci_generic unused=virtio_pci
:08:00.0 'Ethernet Adaptive Virtual Function 1889' drv=uio_pci_generic 
unused=i40evf
:09:00.0 'Ethernet Adaptive Virtual Function 1889' drv=uio_pci_generic 
unused=i40evf

Network devices using kernel driver
===
:02:00.0 'Virtio network device 1041' if=ha0 drv=virt

Re: [dpdk-dev] Not able to start IAVF PMD with dpdk 20.11.3

[Dey, Souvik]

With vfio_pci , I am getting the following error and bind itself is failing, 
due to probe fail with EINVAL.
[root@connexip swe]# ./dpdk-devbind.py -b vfio_pci 08:00.0
Error: bind failed for :08:00.0 - Cannot open 
/sys/bus/pci/drivers/vfio_pci/bind
Sep 24 01:50:29 connexip kernel: [  323.376403] vfio-pci: probe of :08:00.0 
failed with error -22
Sep 24 01:50:29 connexip kernel: [  323.376440] vfio-pci: probe of :08:00.0 
failed with error -22

I am using kernel 4.19.194 from debian buster.

From: Wu, Jingjing 
Sent: Thursday, September 23, 2021 8:41 PM
To: Dey, Souvik ; dev@dpdk.org; Xing, Beilei 

Subject: [EXTERNAL] RE: Not able to start IAVF PMD with dpdk 20.11.3

Could you have a try to switch from  uio_pci_generic to vfio_pci?

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Thursday, September 23, 2021 11:29 PM
To: dev@dpdk.org<mailto:dev@dpdk.org>; Xing, Beilei 
mailto:beilei.x...@intel.com>>; Wu, Jingjing 
mailto:jingjing...@intel.com>>
Subject: Not able to start IAVF PMD with dpdk 20.11.3

Hi All,
 Trying to test E810 Sr-IOV based nic card with 20.11.3 dpdk. I am running 
the host kernel driver and only the VF is attached to the VM where I am running 
dpdk. But when I attaching the VF to the testpmd it is throwing the below 
error. Is there are way to move forward here ?

[root@connexip linuxadmin]# ./dpdk-testpmd -c 0xf -n 4 -a 08:00.0 -- -i 
--rxq=16 --txq=16
EAL: Detected 4 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: Probe PCI driver: net_iavf (8086:1889) device: :08:00.0 (socket 0)
EAL: Error reading from file descriptor 27: Input/output error
EAL: No legacy callbacks, legacy socket not created
Interactive-mode selected
testpmd: create a new mbuf pool : n=171456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will 
pair with itself.

Configuring Port 0 (socket 0)
EAL: Error reading from file descriptor 27: Input/output error
iavf_execute_vf_cmd(): No response for cmd 28
iavf_disable_vlan_strip(): Failed to execute command of 
OP_DISABLE_VLAN_STRIPPING
iavf_execute_vf_cmd(): No response for cmd 24
iavf_configure_rss_lut(): Failed to execute command of OP_CONFIG_RSS_LUT
iavf_dev_configure(): configure rss failed
Port0 dev_configure = -1
Fail to configure port 0
EAL: Error - exiting with code: 1
  Cause: Start ports failed
[root@connexip linuxadmin]#


I do see the matching list for driver but is this required even if I use kernel 
driver on the host and only IAVF PMD on the guest ?

DPDK
Kernel Driver
OS Default DDP
COMMS DDP
Wireless DDP
Firmware
20.11
1.3.2
1.3.20
1.3.24
N/A
2.3
21.02
1.4.11
1.3.24
1.3.28
1.3.4
2.4



Host details:
Red Hat Enterprise Linux release 8.2 (Ootpa)
[root@localhost ~]# modinfo ice
filename:   
/lib/modules/4.18.0-193.19.1.el8_2.x86_64/kernel/drivers/net/ethernet/intel/ice/ice.ko.xz
firmware:   intel/ice/ddp/ice.pkg (ice-1.3.4.0.pkg)
version:0.8.1-k
license:GPL v2
description:Intel(R) Ethernet Connection E800 Series Linux Driver
author: Intel Corporation, 
linux.n...@intel.com<mailto:linux.n...@intel.com>
rhelversion:8.2
Using vfio-pci to connect the VF to the VM.

Guest Details:
OS : debian buster
Dpdk : 20.11.3
Interface bound to uio_pci_generic
[root@connexip linuxadmin]# /opt/sonus/bin/np/swe/dpdk-devbind.py --status

Network devices using DPDK-compatible driver

:01:00.0 'Virtio network device 1041' drv=uio_pci_generic unused=virtio_pci
:08:00.0 'Ethernet Adaptive Virtual Function 1889' drv=uio_pci_generic 
unused=i40evf
:09:00.0 'Ethernet Adaptive Virtual Function 1889' drv=uio_pci_generic 
unused=i40evf

Network devices using kernel driver
===
:02:00.0 'Virtio network device 1041' if=ha0 drv=virtio-pci 
unused=virtio_pci,uio_pci_generic *Active*


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibit

[dpdk-dev] Not able to start IAVF PMD with dpdk 20.11.3

[Dey, Souvik]

Hi All,
 Trying to test E810 Sr-IOV based nic card with 20.11.3 dpdk. I am running 
the host kernel driver and only the VF is attached to the VM where I am running 
dpdk. But when I attaching the VF to the testpmd it is throwing the below 
error. Is there are way to move forward here ?

[root@connexip linuxadmin]# ./dpdk-testpmd -c 0xf -n 4 -a 08:00.0 -- -i 
--rxq=16 --txq=16
EAL: Detected 4 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: Probe PCI driver: net_iavf (8086:1889) device: :08:00.0 (socket 0)
EAL: Error reading from file descriptor 27: Input/output error
EAL: No legacy callbacks, legacy socket not created
Interactive-mode selected
testpmd: create a new mbuf pool : n=171456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will 
pair with itself.

Configuring Port 0 (socket 0)
EAL: Error reading from file descriptor 27: Input/output error
iavf_execute_vf_cmd(): No response for cmd 28
iavf_disable_vlan_strip(): Failed to execute command of 
OP_DISABLE_VLAN_STRIPPING
iavf_execute_vf_cmd(): No response for cmd 24
iavf_configure_rss_lut(): Failed to execute command of OP_CONFIG_RSS_LUT
iavf_dev_configure(): configure rss failed
Port0 dev_configure = -1
Fail to configure port 0
EAL: Error - exiting with code: 1
  Cause: Start ports failed
[root@connexip linuxadmin]#


I do see the matching list for driver but is this required even if I use kernel 
driver on the host and only IAVF PMD on the guest ?

DPDK
Kernel Driver
OS Default DDP
COMMS DDP
Wireless DDP
Firmware
20.11
1.3.2
1.3.20
1.3.24
N/A
2.3
21.02
1.4.11
1.3.24
1.3.28
1.3.4
2.4



Host details:
Red Hat Enterprise Linux release 8.2 (Ootpa)
[root@localhost ~]# modinfo ice
filename:   
/lib/modules/4.18.0-193.19.1.el8_2.x86_64/kernel/drivers/net/ethernet/intel/ice/ice.ko.xz
firmware:   intel/ice/ddp/ice.pkg (ice-1.3.4.0.pkg)
version:0.8.1-k
license:GPL v2
description:Intel(R) Ethernet Connection E800 Series Linux Driver
author: Intel Corporation, 
linux.n...@intel.com
rhelversion:8.2
Using vfio-pci to connect the VF to the VM.

Guest Details:
OS : debian buster
Dpdk : 20.11.3
Interface bound to uio_pci_generic
[root@connexip linuxadmin]# /opt/sonus/bin/np/swe/dpdk-devbind.py --status

Network devices using DPDK-compatible driver

:01:00.0 'Virtio network device 1041' drv=uio_pci_generic unused=virtio_pci
:08:00.0 'Ethernet Adaptive Virtual Function 1889' drv=uio_pci_generic 
unused=i40evf
:09:00.0 'Ethernet Adaptive Virtual Function 1889' drv=uio_pci_generic 
unused=i40evf

Network devices using kernel driver
===
:02:00.0 'Virtio network device 1041' if=ha0 drv=virtio-pci 
unused=virtio_pci,uio_pci_generic *Active*


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

[dpdk-dev] Link status is not coming properly in case of 82599 on VmWare SR-IOV case.

[Dey, Souvik]

Hi All,
 We are seeing a weird issue where the link status of 82599 NIC in SR-IOV 
mode in VmWare is coming as UP even though the vmnic is taken DOWN in the ESXi. 
This is working fine when we use a linux to handle the interface inside of 
DPDK. We are using DPDK 18.11.6 and seeing this issue specific to 
82599(ixgbe_vf) pmd only. The same is working fine in KVM setup also. On 
debugging more on this what we are seeing is that -
On VmWare :
When the link is made down in the esxi, we are getting a IXGBE_VT_MSGTYPE_NACK 
message in the mailbox. The
 links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
 if (!(links_reg & IXGBE_LINKS_UP))
   goto out;
is not hitting and it goes to this section ,
if (!(in_msg & IXGBE_VT_MSGTYPE_CTS)) {
   /* msg is not CTS and is NACK we must have lost CTS status */
   if (in_msg & IXGBE_VT_MSGTYPE_NACK)
mac->get_link_status = false;
   goto out;
 }

And as we are setting the get_link_status to false ,and as it returns the link 
status
*link_up = !mac->get_link_status;
It is becoming as UP.

In KVM setup :
The register read itself is show link down and we are all good there.


On checking why linux is working and not DPDK, we see that in the ixgbevf code 
in linux  , in the function ixgbevf_check_mac_link_vf, we see that

if (!(in_msg & IXGBE_VT_MSGTYPE_CTS)) {

   /* msg is not CTS and is NACK we must have lost CTS status */

   if (in_msg & IXGBE_VT_MSGTYPE_NACK)

   ret_val = -1;

   goto out;

}

It returns an error, but the status is not reset to UP.



So, is the code of setting the link as UP in case of receiving a NACK in the 
mailbox the correct handling or not ? Can some one throw some light on this.



--

Regards,

Souvik


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

[dpdk-dev] [PATCH 19.11 v2] net/mlx5: fix storing the synched MAC to internal table

[Dey, Souvik]

From: Souvik Dey 

[ upstream commit 493f0bb51c1144eedcff2bba199cab1b64ff9fd0 ]

As the internal MAC table is divided into Unicast and Multicast address
sections, we should check the type of synched MAC address before storing
it to the internal table. Currently the check is not done, and the
synched MAC of 33:33:00:00:00:01 gets stored in the unicast section
(mostly index 1) causing all subsequent mlx5_set_mc_addr_list()
to fail with error -EADDRINUSE, as the mac_list contains the MAC
33:33:00:00:00:01. This denies adding of any new multicast address to
the internal list and also fails to add the MAC address to the device
in case of SR-IOV VF.

Fixes: f22442cb5d42 ("net/mlx5: reduce Netlink commands dependencies")
Fixes: ccdcba53a3f4 ("net/mlx5: use Netlink to add/remove MAC addresses")

Signed-off-by: Souvik Dey 
---

v2:
* Fixing the compilation errors.

---
 drivers/net/mlx5/mlx5_nl.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_nl.c b/drivers/net/mlx5/mlx5_nl.c
index 64580b9..6db372e 100644
--- a/drivers/net/mlx5/mlx5_nl.c
+++ b/drivers/net/mlx5/mlx5_nl.c
@@ -678,11 +678,24 @@ mlx5_nl_mac_addr_sync(struct rte_eth_dev *dev)
break;
if (j != MLX5_MAX_MAC_ADDRESSES)
continue;
-   /* Find the first entry available. */
-   for (j = 0; j != MLX5_MAX_MAC_ADDRESSES; ++j) {
-   if (rte_is_zero_ether_addr(&dev->data->mac_addrs[j])) {
-   dev->data->mac_addrs[j] = macs[i];
-   break;
+   if (rte_is_multicast_ether_addr(&dev->data->mac_addrs[j])) {
+   /* Find the first entry available. */
+   for (j = MLX5_MAX_UC_MAC_ADDRESSES;
+   j != MLX5_MAX_MAC_ADDRESSES; ++j) {
+   if (rte_is_zero_ether_addr(
+   &dev->data->mac_addrs[j])) {
+   dev->data->mac_addrs[j] = macs[i];
+   break;
+   }
+   }
+   } else {
+   /* Find the first entry available. */
+   for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j) {
+   if (rte_is_zero_ether_addr(
+   &dev->data->mac_addrs[j])) {
+   dev->data->mac_addrs[j] = macs[i];
+   break;
+   }
}
}
}
-- 
2.9.3.windows.1


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

[dpdk-dev] [PATCH 19.11] net/mlx5: fix storing the synched MAC to internal table

[Dey, Souvik]

From: Souvik Dey 

[ upstream commit 493f0bb51c1144eedcff2bba199cab1b64ff9fd0 ]

As the internal MAC table is divided into Unicast and Multicast address
sections, we should check the type of synched MAC address before storing
it to the internal table. Currently the check is not done, and the
synched MAC of 33:33:00:00:00:01 gets stored in the unicast section
(mostly index 1) causing all subsequent mlx5_set_mc_addr_list()
to fail with error -EADDRINUSE, as the mac_list contains the MAC
33:33:00:00:00:01. This denies adding of any new multicast address to
the internal list and also fails to add the MAC address to the device
in case of SR-IOV VF.

Fixes: f22442cb5d42 ("net/mlx5: reduce Netlink commands dependencies")
Fixes: ccdcba53a3f4 ("net/mlx5: use Netlink to add/remove MAC addresses")

Signed-off-by: Souvik Dey 
---
 drivers/net/mlx5/mlx5_nl.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_nl.c b/drivers/net/mlx5/mlx5_nl.c
index 64580b9..add756d 100644
--- a/drivers/net/mlx5/mlx5_nl.c
+++ b/drivers/net/mlx5/mlx5_nl.c
@@ -678,11 +678,22 @@ mlx5_nl_mac_addr_sync(struct rte_eth_dev *dev)
break;
if (j != MLX5_MAX_MAC_ADDRESSES)
continue;
-   /* Find the first entry available. */
-   for (j = 0; j != MLX5_MAX_MAC_ADDRESSES; ++j) {
-   if (rte_is_zero_ether_addr(&dev->data->mac_addrs[j])) {
-   dev->data->mac_addrs[j] = macs[i];
-   break;
+   if (rte_is_multicast_ether_addr(&macs[i])) {
+   /* Find the first entry available. */
+   for (j = MLX5_MAX_UC_MAC_ADDRESSES;
+j != MLX5_MAX_MAC_ADDRESSES; ++j) {
+   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+   mac_addrs[j] = macs[i];
+   break;
+   }
+   }
+   } else {
+   /* Find the first entry available. */
+   for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j) {
+   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+   mac_addrs[j] = macs[i];
+   break;
+   }
}
}
}
-- 
2.9.3.windows.1


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to internal table

[Dey, Souvik]

Hi Slava,
Initially v2 of the patch has " instead of ' in the Fixes tags, but it 
gave some warnings as wrong quota. So thought of changing it to '. I can change 
it back again, do you suggest me to submit v4 with with corrected quota 
character or its ok to have the v3 of the patch itself as you have already 
acked ?

--
Regards,
Souvik

-Original Message-
From: dev  On Behalf Of Slava Ovsiienko
Sent: Wednesday, February 3, 2021 3:04 AM
To: Dey, Souvik ; Raslan Darawsheh ; Matan 
Azrad 
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to 
internal table

NOTICE: This email was received from an EXTERNAL sender.


Hi,

I'm sorry, but quota character in "Fixes" tags is still wrong, causing the 
checking script errors.
It should be " (0x22 ASCII), not ' (0x27 ASCII).

Beside this:

Acked-by: Viacheslav Ovsiienko 

> -----Original Message-
> From: Dey, Souvik 
> Sent: Tuesday, February 2, 2021 19:49
> To: Raslan Darawsheh ; Slava Ovsiienko 
> ; Matan Azrad ; Shahaf 
> Shuler 
> Cc: dev@dpdk.org; sta...@dpdk.org; Souvik Dey 
> Subject: [PATCH v3] common/mlx5: fix storing the synched MAC to 
> internal table
>
> From: Souvik Dey 
>
> As the internal MAC table is divided into Unicast and Multicast 
> address sections, we should check the type of synched MAC address 
> before storing it to the internal table. Currently the check is not 
> done, and the synched MAC of
> 33:33:00:00:00:01 gets stored in the unicast section (mostly index 1) 
> causing all subsequent mlx5_set_mc_addr_list() to fail with error 
> -EADDRINUSE, as the mac_list contains the MAC 33:33:00:00:00:01. This 
> denies adding of any new multicast address to the internal list and 
> also fails to add the MAC address to the device in case of SR-IOV VF.
>
> Fixes: f22442cb5d42 ('net/mlx5: reduce Netlink commands dependencies')
> Fixes: ccdcba53a3f4 ('net/mlx5: use Netlink to add/remove MAC 
> addresses')
> Cc: sta...@dpdk.org
>
> Signed-off-by: Souvik Dey 
> ---
> v2:
> * net/ -> common/
> * space after mlx5:
> * synched -> synched
> * section -> sections
> * rewording which causes -> causing
> * typo: case (to remove)
> * added Fixes for LTS ML
> ---
> v3:
> * Changed the "" in Fixes tags to ''.
> ---
>  drivers/common/mlx5/linux/mlx5_nl.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/common/mlx5/linux/mlx5_nl.c
> b/drivers/common/mlx5/linux/mlx5_nl.c
> index 40d8620..ef7a521 100644
> --- a/drivers/common/mlx5/linux/mlx5_nl.c
> +++ b/drivers/common/mlx5/linux/mlx5_nl.c
> @@ -758,11 +758,21 @@ mlx5_nl_mac_addr_sync(int nlsk_fd, unsigned int 
> iface_idx,
>   break;
>   if (j != n)
>   continue;
> - /* Find the first entry available. */
> - for (j = 0; j != n; ++j) {
> - if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> - mac_addrs[j] = macs[i];
> - break;
> + if (rte_is_multicast_ether_addr(&macs[i])) {
> + /* Find the first entry available. */
> + for (j = MLX5_MAX_UC_MAC_ADDRESSES; j != n; ++j)
> {
> + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> + mac_addrs[j] = macs[i];
> + break;
> + }
> + }
> + } else {
> + /* Find the first entry available. */
> + for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j)
> {
> + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> + mac_addrs[j] = macs[i];
> + break;
> + }
>   }
>   }
>   }
> --
> 2.9.3.windows.1
>
>

Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

[dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to internal table

[Dey, Souvik]

From: Souvik Dey 

As the internal MAC table is divided into Unicast and Multicast address
sections, we should check the type of synched MAC address before storing
it to the internal table. Currently the check is not done, and the
synched MAC of 33:33:00:00:00:01 gets stored in the unicast section
(mostly index 1) causing all subsequent mlx5_set_mc_addr_list()
to fail with error -EADDRINUSE, as the mac_list contains the MAC
33:33:00:00:00:01. This denies adding of any new multicast address to
the internal list and also fails to add the MAC address to the device
in case of SR-IOV VF.

Fixes: f22442cb5d42 ('net/mlx5: reduce Netlink commands dependencies')
Fixes: ccdcba53a3f4 ('net/mlx5: use Netlink to add/remove MAC addresses')
Cc: sta...@dpdk.org

Signed-off-by: Souvik Dey 
---
v2:
* net/ -> common/
* space after mlx5:
* synched -> synched
* section -> sections
* rewording which causes -> causing 
* typo: case (to remove)
* added Fixes for LTS ML
---
v3:
* Changed the "" in Fixes tags to ''.
---
 drivers/common/mlx5/linux/mlx5_nl.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/common/mlx5/linux/mlx5_nl.c 
b/drivers/common/mlx5/linux/mlx5_nl.c
index 40d8620..ef7a521 100644
--- a/drivers/common/mlx5/linux/mlx5_nl.c
+++ b/drivers/common/mlx5/linux/mlx5_nl.c
@@ -758,11 +758,21 @@ mlx5_nl_mac_addr_sync(int nlsk_fd, unsigned int iface_idx,
break;
if (j != n)
continue;
-   /* Find the first entry available. */
-   for (j = 0; j != n; ++j) {
-   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
-   mac_addrs[j] = macs[i];
-   break;
+   if (rte_is_multicast_ether_addr(&macs[i])) {
+   /* Find the first entry available. */
+   for (j = MLX5_MAX_UC_MAC_ADDRESSES; j != n; ++j) {
+   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+   mac_addrs[j] = macs[i];
+   break;
+   }
+   }
+   } else {
+   /* Find the first entry available. */
+   for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j) {
+   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+   mac_addrs[j] = macs[i];
+   break;
+   }
}
}
}
-- 
2.9.3.windows.1


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

[dpdk-dev] [PATCH v2] common/mlx5: fix storing the synched MAC to internal table

[Dey, Souvik]

From: Souvik Dey 

As the internal MAC table is divided into Unicast and Multicast address
sections, we should check the type of synched MAC address before storing
it to the internal table. Currently the check is not done, and the
synched MAC of 33:33:00:00:00:01 gets stored in the unicast section
(mostly index 1) causing all subsequent mlx5_set_mc_addr_list()
to fail with error -EADDRINUSE, as the mac_list contains the MAC
33:33:00:00:00:01. This denies adding of any new multicast address to
the internal list and also fails to add the MAC address to the device
in case of SR-IOV VF.

Fixes: f22442cb5d42 (�net/mlx5: reduce Netlink commands dependencies�)
Fixes: ccdcba53a3f4 (�net/mlx5: use Netlink to add/remove MAC addresses�)
Cc: sta...@dpdk.org

Signed-off-by: Souvik Dey 
---
v2:
* net/ -> common/
* space after mlx5:
* synched -> synched
* section -> sections
* rewording which causes -> causing 
* typo: case (to remove)
* added Fixes for LTS ML
---
 drivers/common/mlx5/linux/mlx5_nl.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/common/mlx5/linux/mlx5_nl.c 
b/drivers/common/mlx5/linux/mlx5_nl.c
index 40d8620..ef7a521 100644
--- a/drivers/common/mlx5/linux/mlx5_nl.c
+++ b/drivers/common/mlx5/linux/mlx5_nl.c
@@ -758,11 +758,21 @@ mlx5_nl_mac_addr_sync(int nlsk_fd, unsigned int iface_idx,
break;
if (j != n)
continue;
-   /* Find the first entry available. */
-   for (j = 0; j != n; ++j) {
-   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
-   mac_addrs[j] = macs[i];
-   break;
+   if (rte_is_multicast_ether_addr(&macs[i])) {
+   /* Find the first entry available. */
+   for (j = MLX5_MAX_UC_MAC_ADDRESSES; j != n; ++j) {
+   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+   mac_addrs[j] = macs[i];
+   break;
+   }
+   }
+   } else {
+   /* Find the first entry available. */
+   for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j) {
+   if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+   mac_addrs[j] = macs[i];
+   break;
+   }
}
}
}
-- 
2.9.3.windows.1


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: [dpdk-dev] [PATCH v2] net/i40e: issue with ADD VLAN from Guest

[Dey, Souvik]

Hi Guo,
Raised the v3 of the patch , but was not sure how to put the ACK. If you don’t 
mind can you please ACK the same. Thanks.
https://patchwork.dpdk.org/patch/85210/

--
Regards,
Souvik

From: Dey, Souvik
Sent: Tuesday, December 15, 2020 8:16 AM
To: Guo, Jia ; Xing, Beilei ; Zhang, 
Qi Z 
Cc: dev@dpdk.org
Subject: RE: [PATCH v2] net/i40e: issue with ADD VLAN from Guest

Hi Guo,

Ok sure will remove the extra log and submit the version 3. I have not received 
any other comments , so will also add your ACK in the next version then.

--
Regards,
Souvik

From: Guo, Jia mailto:jia@intel.com>>
Sent: Monday, December 14, 2020 9:24 PM
To: Dey, Souvik mailto:so...@rbbn.com>>; Xing, Beilei 
mailto:beilei.x...@intel.com>>; Zhang, Qi Z 
mailto:qi.z.zh...@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: [PATCH v2] net/i40e: issue with ADD VLAN from Guest


NOTICE: This email was received from an EXTERNAL sender



From: Souvik Dey mailto:so...@rbbn.com>>
Sent: Saturday, December 12, 2020 9:05 PM
To: Xing, Beilei mailto:beilei.x...@intel.com>>; Guo, 
Jia mailto:jia@intel.com>>; Zhang, Qi Z 
mailto:qi.z.zh...@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; Souvik Dey 
mailto:so...@rbbn.com>>
Subject: [PATCH v2] net/i40e: issue with ADD VLAN from Guest

Reset the configuration of vlan strip that would be change
by the pf kernel driver when adding vlan from vf.
Application cannot use rte_eth_dev_set_vlan_offload() to set
the VLAN_STRIP, as this will only work for the first time when
original and current config mismatch, but for all subsequent call
it will be ignored.

Signed-off-by: Souvik Dey mailto:so...@rbbn.com>>
---
v2:
* Simplied the commit log.
* goto err; is not required as it has only one more return path
and there is no cleanup required apart from just return err.
* Updated the comment start from /* -> /**
* Changed the error log in case vlan strip command fails.
---
drivers/net/i40e/i40e_ethdev_vf.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index c26b036..d3dbcb5 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1078,8 +1078,19 @@ i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid)
args.out_buffer = vf->aq_resp;
args.out_size = I40E_AQ_BUF_SZ;
err = i40evf_execute_vf_cmd(dev, &args);
- if (err)
+ if (err) {
PMD_DRV_LOG(ERR, "fail to execute command OP_ADD_VLAN");
+ return err;
+ }
+ /**
+ * In linux kernel driver on receiving ADD_VLAN it enables
+ * VLAN_STRIP by default. So reconfigure the vlan_offload
+ * as it was done by the app earlier.
+ */
+ err = i40evf_vlan_offload_set(dev, ETH_VLAN_STRIP_MASK);
+ if (err)
+ PMD_DRV_LOG(ERR, "fail to set vlan_strip "
+ "as a part of OP_ADD_VLAN");

What I mean is that “PMD_DRV_LOG(ERR, "fail to set vlan strip");” is enough, 
since it will make the driver log to be
more simple. And also avoid a quoted string split across lines which let the 
second line could not hit your expectation.
Other look good, if no other comment, please add my ACK in your next version, 
thanks.

return err;
}
--
2.9.3.windows.1


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that is confidential and/or proprietary for the sole 
use of the intended recipient. Any review, disclosure, reliance or distribution 
by others or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

Re: [dpdk-dev] [PATCH v2] net/i40e: issue with ADD VLAN from Guest

[Dey, Souvik]

Hi Guo,

Ok sure will remove the extra log and submit the version 3. I have not received 
any other comments , so will also add your ACK in the next version then.

--
Regards,
Souvik

From: Guo, Jia 
Sent: Monday, December 14, 2020 9:24 PM
To: Dey, Souvik ; Xing, Beilei ; Zhang, 
Qi Z 
Cc: dev@dpdk.org
Subject: RE: [PATCH v2] net/i40e: issue with ADD VLAN from Guest


NOTICE: This email was received from an EXTERNAL sender



From: Souvik Dey mailto:so...@rbbn.com>>
Sent: Saturday, December 12, 2020 9:05 PM
To: Xing, Beilei mailto:beilei.x...@intel.com>>; Guo, 
Jia mailto:jia@intel.com>>; Zhang, Qi Z 
mailto:qi.z.zh...@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; Souvik Dey 
mailto:so...@rbbn.com>>
Subject: [PATCH v2] net/i40e: issue with ADD VLAN from Guest

Reset the configuration of vlan strip that would be change
by the pf kernel driver when adding vlan from vf.
Application cannot use rte_eth_dev_set_vlan_offload() to set
the VLAN_STRIP, as this will only work for the first time when
original and current config mismatch, but for all subsequent call
it will be ignored.

Signed-off-by: Souvik Dey mailto:so...@rbbn.com>>
---
v2:
* Simplied the commit log.
* goto err; is not required as it has only one more return path
and there is no cleanup required apart from just return err.
* Updated the comment start from /* -> /**
* Changed the error log in case vlan strip command fails.
---
drivers/net/i40e/i40e_ethdev_vf.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index c26b036..d3dbcb5 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1078,8 +1078,19 @@ i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid)
args.out_buffer = vf->aq_resp;
args.out_size = I40E_AQ_BUF_SZ;
err = i40evf_execute_vf_cmd(dev, &args);
- if (err)
+ if (err) {
PMD_DRV_LOG(ERR, "fail to execute command OP_ADD_VLAN");
+ return err;
+ }
+ /**
+ * In linux kernel driver on receiving ADD_VLAN it enables
+ * VLAN_STRIP by default. So reconfigure the vlan_offload
+ * as it was done by the app earlier.
+ */
+ err = i40evf_vlan_offload_set(dev, ETH_VLAN_STRIP_MASK);
+ if (err)
+ PMD_DRV_LOG(ERR, "fail to set vlan_strip "
+ "as a part of OP_ADD_VLAN");


What I mean is that “PMD_DRV_LOG(ERR, "fail to set vlan strip");” is enough, 
since it will make the driver log to be
more simple. And also avoid a quoted string split across lines which let the 
second line could not hit your expectation.
Other look good, if no other comment, please add my ACK in your next version, 
thanks.

return err;
}
--
2.9.3.windows.1



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that is confidential and/or proprietary for the sole 
use of the intended recipient. Any review, disclosure, reliance or distribution 
by others or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

Re: [dpdk-dev] [PATCH] net/i40e: issue with ADD VLAN from Guest

[Dey, Souvik]

Hi Guo,
  Thanks for the comments. I will upload a v2 of the patch.

--
Regards,
Souvik

From: Guo, Jia 
Sent: Thursday, December 10, 2020 10:08 PM
To: Dey, Souvik ; Xing, Beilei ; Zhang, 
Qi Z 
Cc: dev@dpdk.org
Subject: RE: [PATCH] net/i40e: issue with ADD VLAN from Guest


NOTICE: This email was received from an EXTERNAL sender


hi, souvik

From: Souvik Dey mailto:so...@rbbn.com>>
Sent: Thursday, December 10, 2020 1:55 AM
To: Xing, Beilei mailto:beilei.x...@intel.com>>; Guo, 
Jia mailto:jia@intel.com>>; Zhang, Qi Z 
mailto:qi.z.zh...@intel.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; Souvik Dey 
mailto:so...@rbbn.com>>
Subject: [PATCH] net/i40e: issue with ADD VLAN from Guest

In case of i40evf pmd, when ADD_VLAN is sent down the linux i40e driver,
along with add the vlan the kernel driver also enables the vlan stripping
by default.
This might have issues if the app configured DEV_RX_OFFLOAD_VLAN_STRIP
as off at the port configuration. The app after adding the VLAN will
expect the VLAN to be coming in the received packets but, due to
VLAN_STRIP enabled at the PF, it will get stripped.
This behavior of the Linux driver causes confussion with the DPDK app
using i40e_pmd. So it is better to reconfigure the vlan_offload, which
checks for DEV_RX_OFFLOAD_VLAN_STRIP flag in the dev_conf and enables or
disables the vlan strip in the PF.
Also rte_eth_dev_set_vlan_offload() to disable VLAN_STRIP cannot be used
from the application, as this will only work for the first time when
original and current confi mismatch, but for all subsequent call it will
ignore it.


Thanks for your patch and the clear detail interpret, what you said is reset 
the configuration about vlan strip that
would be change by the pf driver when adding vlan from vf, so I think 
concentrate<http://www.baidu.com/link?url=FKtXEQdgI9iuD4HN0uZIpf5hHCbYVGlPJx-jzQ-bGjXQiZutjIi6XT6rPlEoGfM13HvgvT9Gt88OAPmEKXNitp-rKK4k50M6di1HF4bDMxa&wd=&eqid=e7f451dc0001a61100045fd2e0e1>
 the commit log to be more simple
in your way would be enough.

Signed-off-by: Souvik Dey mailto:so...@rbbn.com>>
---
drivers/net/i40e/i40e_ethdev_vf.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index c26b036..2ecf74b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1078,8 +1078,19 @@ i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid)
args.out_buffer = vf->aq_resp;
args.out_size = I40E_AQ_BUF_SZ;
err = i40evf_execute_vf_cmd(dev, &args);
- if (err)
+ if (err) {
PMD_DRV_LOG(ERR, "fail to execute command OP_ADD_VLAN");
+ return err;

Would it be more code clean to use “goto err;”?

+ }
+ /*

/* -> /**, that would what I suggest.

+ * In linux kernel driver on receiving ADD_VLAN it enables
+ * VLAN_STRIP by default. So reconfigure the vlan_offload
+ * as it was done by the app earlier.
+ */
+ err = i40evf_vlan_offload_set(dev, ETH_VLAN_STRIP_MASK);
+ if (err)
+ PMD_DRV_LOG(ERR, "fail to execute command disable_vlan_strip "
+ "as a part of OP_ADD_VLAN");

If it is not coming as a command, please refine this log, such as “fail to set 
vlan strip.”


return err;
}
--
2.9.3.windows.1



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that is confidential and/or proprietary for the sole 
use of the intended recipient. Any review, disclosure, reliance or distribution 
by others or forwarding without express permission is strictly prohibited. If 
you are not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

[dpdk-dev] DPDK AF_XDP test results.

[Dey, Souvik]

Hi All,
  There is a test plan for the performance tests of different 
scenarios with AF_XDP in the dpdk docs  
https://doc.dpdk.org/dts/test_plans/af_xdp_test_plan.html , but I am not able 
to find the test  results of the same. Can anyone please help in sharing the 
results link for these tests. We are starting to look at AF_XDP with DPDK and 
these results will really help us in deciding few points. Also it will be 
really appreciated if we have some comparative study of using SR-IOV + DPDK PMD 
vs XDP + AF_XDP DPDK PMD. Thanks for the help in this regard.

--
Thanks,
Souvik

[dpdk-dev] net/bnx2x: Qlogic nic card support (1077:16a1)

[Dey, Souvik]

Hi All,
  I see that the linux bnx2x driver supports the following vendor id : 
device id


  *   vendor: 1077 ("QLogic Corp."), device: 16a1
  *   vendor: 1077 ("QLogic Corp."), device: 16a4
  *   vendor: 1077 ("QLogic Corp."), device: 16ad

but this are not supported by the bnx2x_pmd. This combination is not even 
supported by the qede_pmd. Does this mean that this device is not supported by 
dpdk even though linux driver supports it ? I am currently using 18.11.10 dpdk 
version but did check the latest code too and don't see this devices supported. 
Can you please update me on this. We are trying to using the HPE FlxFbrc 10Gb 
4p 536FLR-T Adptr( 
specs), the 
57840S 10 Gb Ethernet controller f in a PCIe 3.0 compliant form factor designed 
for HPE ProLiant servers.
lspci -nnn | grep Ether
04:00.0 Ethernet controller [0200]: QLogic Corp. Device [1077:16a1] (rev 11)
04:00.1 Ethernet controller [0200]: QLogic Corp. Device [1077:16a1] (rev 11)
04:00.2 Ethernet controller [0200]: QLogic Corp. Device [1077:16a1] (rev 11)
04:00.3 Ethernet controller [0200]: QLogic Corp. Device [1077:16a1] (rev 11)
04:01.0 Ethernet controller [0200]: QLogic Corp. Device [1077:16ad]
04:01.1 Ethernet controller [0200]: QLogic Corp. Device [1077:16ad]
04:01.2 Ethernet controller [0200]: QLogic Corp. Device [1077:16ad]
04:01.3 Ethernet controller [0200]: QLogic Corp. Device [1077:16ad]

Kernel code :
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c

{ 
PCI_VDEVICE(BROADCOM,
 
PCI_DEVICE_ID_NX2_57840_4_10),
 BCM57840_4_10 },

{ 
PCI_VDEVICE(QLOGIC,
   
PCI_DEVICE_ID_NX2_57840_4_10),
 BCM57840_4_10 },

{ 
PCI_VDEVICE(BROADCOM,
 
PCI_DEVICE_ID_NX2_57840_MF),
 BCM57840_MF },

{ 
PCI_VDEVICE(QLOGIC,
   
PCI_DEVICE_ID_NX2_57840_MF),
 BCM57840_MF },

{ 
PCI_VDEVICE(BROADCOM,
 
PCI_DEVICE_ID_NX2_57840_VF),
 BCM57840_VF },

{ 
PCI_VDEVICE(QLOGIC,
   
PCI_DEVICE_ID_NX2_57840_VF),
 BCM57840_VF },

DPDK code:
net/bnx2x_ethdev.c
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_4_10) },
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_MF) },
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_VF) },

Are we missing the vendor id in the dpdk code which is causing this or there 
are more changes required to support this card ?
Thanks in advance for the help. Racing against time to support this card, so 
any prompt reply will be highly appreciated.

--
Regards,
Souvik

Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

Hi Long,
  Yes the below patch helped in getting the tx path issue resolved in 
18.11.9. Thank you very much for the help. I think it will be really good to 
have this patch include in 18.11.10 too.
Current status:
18.11.9 –
1. Required 2 patches on top of 18.11.9 to make it work.
  a. 
https://patches.dpdk.org/patch/75001/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F75001%2F&data=02%7C01%7Clongli%40microsoft.com%7C7966b9e87a6948f2487a08d85b19e667%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359514090710567&sdata=gBu6wsS%2F7X695EL9nkpWvjA0KunV0cHOvgJSrHjyGog%3D&reserved=0>
  b. the below patch.
18.11.10 –
  1. Still facing rx path issue as explained below, where the rx mbuf is 
not  making it through the kni interface. As RX path packets are not coming up 
to the kernel, dhcp is failing and could not test the tx path with big packets. 
Also Arp packets are failing to reach through the kni interface.

Again, thanks a ton for the 18.11.9 Tx path issue resolution.

--
Regards,
Souvik

From: Long Li 
Sent: Friday, September 18, 2020 3:09 AM
To: Dey, Souvik ; Kevin Traynor ; 
dev@dpdk.org
Cc: Stephen Hemminger ; Yigit, Ferruh 
; Stephen Hemminger 
Subject: Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


Can you apply the following patch to see if it helps?

diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index 813f8c3cc..8359cc121 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -160,8 +160,8 @@ static void hn_txd_init(struct rte_mempool *mp __rte_unused,

txd->queue_id = txq->queue_id;
txd->chim_index = NVS_CHIM_IDX_INVALID;
-   txd->rndis_pkt = (struct rndis_packet_msg *)(char *)txq->tx_rndis
-   + idx * HN_RNDIS_PKT_ALIGNED;
+   txd->rndis_pkt = (struct rndis_packet_msg *)((char *)txq->tx_rndis
+   + idx * HN_RNDIS_PKT_ALIGNED);
 }

 int

________
From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Thursday, September 17, 2020 7:54 AM
To: Long Li mailto:lon...@microsoft.com>>; Kevin Traynor 
mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org> mailto:dev@dpdk.org>>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


I have taken all the available approved patches from DPDK patchwork, but still 
Rx is not working properly.



A bit of summary:

With 18.11.6 – everything works fine.

With 18.11.9 –

  1.  Seg fault in tx path. Ported the 
https://patches.dpdk.org/patch/75001/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F75001%2F&data=02%7C01%7Clongli%40microsoft.com%7C7966b9e87a6948f2487a08d85b19e667%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359514090710567&sdata=gBu6wsS%2F7X695EL9nkpWvjA0KunV0cHOvgJSrHjyGog%3D&reserved=0>
 patch to fix that.
  2.  Large tx packets fail to go out with the following error - 
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2. 
Looks like the changes done in the 
https://patches.dpdk.org/patch/67511/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F67511%2F&data=02%7C01%7Clongli%40microsoft.com%7C7966b9e87a6948f2487a08d85b19e667%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359514090715556&sdata=P3WhHszzSZtY3x1uFCBif1urLsEV47hEQhPD5GFl2X0%3D&reserved=0>
 is causing the issue.

Tried will all the available approved patches in dpdk on top on 18.11.9 –

  1.  RX stopped working . Packets comes up to the dpdk app but is not 
delivered to the kernel through kni interface. So could not test tx patch as 
dhcp is failing. I believe the patch 
https://patches.dpdk.org/patch/75341/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F75341%2F&data=02%7C01%7Clongli%40microsoft.com%7C7966b9e87a6948f2487a08d85b19e667%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359514090720550&sdata=AMtDlizGrElXSuGCoAv40cSTSyYsXlkoGUVTMZe69ko%3D&reserved=0>
 might be causing this.



It looks like definitely the patches are proper but something is wrong in the 
setup or the way packets are following. Just that everything worked fine till 
18.11.8.

My setup is that



Kernel === kni interface === dpdk app === pmd .



Any further insight will be really valuable.. Thanks.



--

Regards,

Souvik



From: Long Li mailto:lon...@microsoft.com>>
Sent: Thursday, September 17, 2020 2:58 AM
To: Dey, Souvik mailto:so...@rbbn.com>>; Kevin Traynor 
mailto:ktray...@redhat.com>>; 
dev@dpdk.org&l

Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

I have taken all the available approved patches from DPDK patchwork, but still 
Rx is not working properly.

A bit of summary:
With 18.11.6 – everything works fine.
With 18.11.9 –

  1.  Seg fault in tx path. Ported the https://patches.dpdk.org/patch/75001/ 
patch to fix that.
  2.  Large tx packets fail to go out with the following error - 
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2. 
Looks like the changes done in the https://patches.dpdk.org/patch/67511/ is 
causing the issue.
Tried will all the available approved patches in dpdk on top on 18.11.9 –

  1.  RX stopped working . Packets comes up to the dpdk app but is not 
delivered to the kernel through kni interface. So could not test tx patch as 
dhcp is failing. I believe the patch https://patches.dpdk.org/patch/75341/ 
might be causing this.

It looks like definitely the patches are proper but something is wrong in the 
setup or the way packets are following. Just that everything worked fine till 
18.11.8.
My setup is that

Kernel === kni interface === dpdk app === pmd .

Any further insight will be really valuable.. Thanks.

--
Regards,
Souvik

From: Long Li 
Sent: Thursday, September 17, 2020 2:58 AM
To: Dey, Souvik ; Kevin Traynor ; 
dev@dpdk.org
Cc: Stephen Hemminger ; Yigit, Ferruh 
; Stephen Hemminger 
Subject: Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


The patch below is correct. I'm wondering if you have missed another patch. The 
most suspects are "77cf88c0c6 net/netvsc: fix underflow when Rx external mbuf" 
and 
https://patches.dpdk.org/patch/67511/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F67511%2F&data=02%7C01%7Clongli%40microsoft.com%7C0b9366f76a924fbfa06c08d85a8d1e0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358909438821452&sdata=ARiQNKn627v%2Bssux2ZF73YQDr1%2BEfXSYjteyN9LuMfw%3D&reserved=0>.
 Can you confirm you have those?

Do you have the log from "--log-level pmd.netvsc:debug" on the new failure?

Also, it seems you are running with "-vdev=net_vdev_netvsc0,iface=mlxhvpkt0 
--vdev=net_vdev_netvsc1,iface=mlxhvpkt1", I'm not entirely sure how netvsc pmd 
is involved.

Can you provide some details on your setup? I'll try to repro it to see if I 
can hit the failure.



From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Wednesday, September 16, 2020 3:07 PM
To: Long Li mailto:lon...@microsoft.com>>; Kevin Traynor 
mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org> mailto:dev@dpdk.org>>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


Looks like the below patch has changes a lot in the tx path which came in 
18.11.9. Verified till 18.11.8 everything is working as expected.



https://patches.dpdk.org/patch/67511/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F67511%2F&data=02%7C01%7Clongli%40microsoft.com%7C0b9366f76a924fbfa06c08d85a8d1e0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358909438821452&sdata=ARiQNKn627v%2Bssux2ZF73YQDr1%2BEfXSYjteyN9LuMfw%3D&reserved=0>



Can you confirm if this change or the recv change patch proposed below will 
require any specific device config change as my same app does not work any 
longer.



--

Regards,

Souvik



From: Dey, Souvik
Sent: Wednesday, September 16, 2020 4:32 PM
To: Long Li mailto:lon...@microsoft.com>>; Kevin Traynor 
mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9



If it helps the tx_conf->tx_free_thresh is set to 0 from app side and nb_desc 
is set to 4096 from the app. The same was set in 18.11.6 too.



From: Dey, Souvik
Sent: Wednesday, September 16, 2020 3:44 PM
To: 'Long Li' mailto:lon...@microsoft.com>>; Kevin 
Traynor mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9



Hi Long,



I did take this patch on top of 18.11.10rc1 , but with this patch and also with 
18.11.10rc1 files, the rx itself is not working and dhcp fails. With 18.11.9 
the rx is working fine and changes present in 18.11.10rc1(hn_rxtx.c  ) does not 

Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

Looks like the below patch has changes a lot in the tx path which came in 
18.11.9. Verified till 18.11.8 everything is working as expected.

https://patches.dpdk.org/patch/67511/

Can you confirm if this change or the recv change patch proposed below will 
require any specific device config change as my same app does not work any 
longer.

--
Regards,
Souvik

From: Dey, Souvik
Sent: Wednesday, September 16, 2020 4:32 PM
To: Long Li ; Kevin Traynor ; 
dev@dpdk.org
Cc: Stephen Hemminger ; Yigit, Ferruh 
; Stephen Hemminger 
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

If it helps the tx_conf->tx_free_thresh is set to 0 from app side and nb_desc 
is set to 4096 from the app. The same was set in 18.11.6 too.

From: Dey, Souvik
Sent: Wednesday, September 16, 2020 3:44 PM
To: 'Long Li' mailto:lon...@microsoft.com>>; Kevin 
Traynor mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

Hi Long,

I did take this patch on top of 18.11.10rc1 , but with this patch and also with 
18.11.10rc1 files, the rx itself is not working and dhcp fails. With 18.11.9 
the rx is working fine and changes present in 18.11.10rc1(hn_rxtx.c  ) does not 
look to work. 18.11.6 was all proper but 18.11.9 is not helping. I am not using 
testpmd but using our own dpdk app on Azure.
We are using the below command line args:
-c 0xe -n 3 -w 83f0:00:02.0 -w 8cb0:00:02.0 
--vdev=net_vdev_netvsc0,iface=mlxhvpkt0 --vdev=net_vdev_netvsc1,iface=mlxhvpkt1 
--log-level pmd.netvsc:debug --proc-type=primary

Thanks in advance for all the help.

--
Regards,
Souvik

From: Long Li mailto:lon...@microsoft.com>>
Sent: Wednesday, September 16, 2020 1:44 PM
To: Dey, Souvik mailto:so...@rbbn.com>>; Kevin Traynor 
mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

Please also pick up this patch:
https://patchwork.dpdk.org/patch/75341/<https://patchwork.dpdk.org/patch/75341>

This patch didn’t make it to 18.11.

Let me know if you are still seeing failures. If you can reproduce the failure 
with testpmd or other tools in DPDK, please also share the command you used.

Thanks,
Long

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Wednesday, September 16, 2020 7:41 AM
To: Kevin Traynor mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Long Li 
mailto:lon...@microsoft.com>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

Yes the patch solves the seg fault issue, but even after backporting the patch 
we are not able to send packets with size higher than 512. The packets not 
being transmitted is the real problem here. I have also tried to take the 
18.11.10rc1 build but faced similar issues in transmitting the packets.

--
Regards,
Souvik

From: dev mailto:dev-boun...@dpdk.org>> On Behalf Of 
Kevin Traynor
Sent: Wednesday, September 16, 2020 10:18 AM
To: Dey, Souvik mailto:so...@rbbn.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; 
lon...@microsoft.com<mailto:lon...@microsoft.com>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; 
sthem...@microsoft.com<mailto:sthem...@microsoft.com>
Subject: Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


On 16/09/2020 13:00, Dey, Souvik wrote:
> Hi All,
> I updated from dpdk 18.11.6 to 18.11.9 and my netvsc pmd stopped working as 
> expected. Firstly, I saw a crash in tx packets as soon as the dpdk app comes 
> up. In doing some googling found a bug that was fixed after 18.11.9 
> https://patches.dpdk.org/patch/75001/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F75001&data=02%7C01%7Clongli%40microsoft.com%7C1f1640e423394eb94f6e08d85a4ee081%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358642130122587&sdata=Y9OdJYjrfRA2uDr%2Bs%2FMyqmYFZjPwsXPWV%2BvYWVTSy04%3D&reserved=0>
>  . Ported this fix and was able to get rid of the seg fault, but now stuck at 
> another issue. When we are transmitting pac

Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

If it helps the tx_conf->tx_free_thresh is set to 0 from app side and nb_desc 
is set to 4096 from the app. The same was set in 18.11.6 too.

From: Dey, Souvik
Sent: Wednesday, September 16, 2020 3:44 PM
To: 'Long Li' ; Kevin Traynor ; 
dev@dpdk.org
Cc: Stephen Hemminger ; Yigit, Ferruh 
; Stephen Hemminger 
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

Hi Long,

I did take this patch on top of 18.11.10rc1 , but with this patch and also with 
18.11.10rc1 files, the rx itself is not working and dhcp fails. With 18.11.9 
the rx is working fine and changes present in 18.11.10rc1(hn_rxtx.c  ) does not 
look to work. 18.11.6 was all proper but 18.11.9 is not helping. I am not using 
testpmd but using our own dpdk app on Azure.
We are using the below command line args:
-c 0xe -n 3 -w 83f0:00:02.0 -w 8cb0:00:02.0 
--vdev=net_vdev_netvsc0,iface=mlxhvpkt0 --vdev=net_vdev_netvsc1,iface=mlxhvpkt1 
--log-level pmd.netvsc:debug --proc-type=primary

Thanks in advance for all the help.

--
Regards,
Souvik

From: Long Li mailto:lon...@microsoft.com>>
Sent: Wednesday, September 16, 2020 1:44 PM
To: Dey, Souvik mailto:so...@rbbn.com>>; Kevin Traynor 
mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

Please also pick up this patch:
https://patchwork.dpdk.org/patch/75341/<https://patchwork.dpdk.org/patch/75341>

This patch didn’t make it to 18.11.

Let me know if you are still seeing failures. If you can reproduce the failure 
with testpmd or other tools in DPDK, please also share the command you used.

Thanks,
Long

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Wednesday, September 16, 2020 7:41 AM
To: Kevin Traynor mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Long Li 
mailto:lon...@microsoft.com>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

Yes the patch solves the seg fault issue, but even after backporting the patch 
we are not able to send packets with size higher than 512. The packets not 
being transmitted is the real problem here. I have also tried to take the 
18.11.10rc1 build but faced similar issues in transmitting the packets.

--
Regards,
Souvik

From: dev mailto:dev-boun...@dpdk.org>> On Behalf Of 
Kevin Traynor
Sent: Wednesday, September 16, 2020 10:18 AM
To: Dey, Souvik mailto:so...@rbbn.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; 
lon...@microsoft.com<mailto:lon...@microsoft.com>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; 
sthem...@microsoft.com<mailto:sthem...@microsoft.com>
Subject: Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

________
NOTICE: This email was received from an EXTERNAL sender


On 16/09/2020 13:00, Dey, Souvik wrote:
> Hi All,
> I updated from dpdk 18.11.6 to 18.11.9 and my netvsc pmd stopped working as 
> expected. Firstly, I saw a crash in tx packets as soon as the dpdk app comes 
> up. In doing some googling found a bug that was fixed after 18.11.9 
> https://patches.dpdk.org/patch/75001/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F75001&data=02%7C01%7Clongli%40microsoft.com%7C1f1640e423394eb94f6e08d85a4ee081%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358642130122587&sdata=Y9OdJYjrfRA2uDr%2Bs%2FMyqmYFZjPwsXPWV%2BvYWVTSy04%3D&reserved=0>
>  . Ported this fix and was able to get rid of the seg fault, but now stuck at 
> another issue. When we are transmitting packets of size within 
> HN_TXCOPY_THRESHOLD we

Hi,

The patch mentioned is merged to the 18.11 branch in dpdk-stable repo
and part of 18.11.10-rc1, so expected to be in 18.11.10. ETA 28th September.

In case it's already fixed, you can try the 18.11.10-rc1 release. These
netvsc backports were added since 18.11.9. The corresponding dpdk main
commit id's are in the full log.

$ git log --oneline v18.11.9..HEAD .
363bdf0f49 net/netvsc: fix chimney index
5b3a327709 net/netvsc: fix crash during Tx
77cf88c0c6 net/netvsc: fix underflow when Rx external mbuf
592571 net/netvsc: do not spin forever waiting for reply

The list of fixes that were tagged for stable but not backported is
here:
http://inbox.dpdk.org/stable/20200901100115.72365-1-ktray...@redhat.com/<https://

Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

Hi Long,

I did take this patch on top of 18.11.10rc1 , but with this patch and also with 
18.11.10rc1 files, the rx itself is not working and dhcp fails. With 18.11.9 
the rx is working fine and changes present in 18.11.10rc1(hn_rxtx.c  ) does not 
look to work. 18.11.6 was all proper but 18.11.9 is not helping. I am not using 
testpmd but using our own dpdk app on Azure.
We are using the below command line args:
-c 0xe -n 3 -w 83f0:00:02.0 -w 8cb0:00:02.0 
--vdev=net_vdev_netvsc0,iface=mlxhvpkt0 --vdev=net_vdev_netvsc1,iface=mlxhvpkt1 
--log-level pmd.netvsc:debug --proc-type=primary

Thanks in advance for all the help.

--
Regards,
Souvik

From: Long Li 
Sent: Wednesday, September 16, 2020 1:44 PM
To: Dey, Souvik ; Kevin Traynor ; 
dev@dpdk.org
Cc: Stephen Hemminger ; Yigit, Ferruh 
; Stephen Hemminger 
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

Please also pick up this patch:
https://patchwork.dpdk.org/patch/75341/<https://patchwork.dpdk.org/patch/75341>

This patch didn’t make it to 18.11.

Let me know if you are still seeing failures. If you can reproduce the failure 
with testpmd or other tools in DPDK, please also share the command you used.

Thanks,
Long

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Wednesday, September 16, 2020 7:41 AM
To: Kevin Traynor mailto:ktray...@redhat.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; Long Li 
mailto:lon...@microsoft.com>>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; Stephen Hemminger 
mailto:sthem...@microsoft.com>>
Subject: RE: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

Yes the patch solves the seg fault issue, but even after backporting the patch 
we are not able to send packets with size higher than 512. The packets not 
being transmitted is the real problem here. I have also tried to take the 
18.11.10rc1 build but faced similar issues in transmitting the packets.

--
Regards,
Souvik

From: dev mailto:dev-boun...@dpdk.org>> On Behalf Of 
Kevin Traynor
Sent: Wednesday, September 16, 2020 10:18 AM
To: Dey, Souvik mailto:so...@rbbn.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Stephen Hemminger 
mailto:step...@networkplumber.org>>; 
lon...@microsoft.com<mailto:lon...@microsoft.com>; Yigit, Ferruh 
mailto:ferruh.yi...@intel.com>>; 
sthem...@microsoft.com<mailto:sthem...@microsoft.com>
Subject: Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


On 16/09/2020 13:00, Dey, Souvik wrote:
> Hi All,
> I updated from dpdk 18.11.6 to 18.11.9 and my netvsc pmd stopped working as 
> expected. Firstly, I saw a crash in tx packets as soon as the dpdk app comes 
> up. In doing some googling found a bug that was fixed after 18.11.9 
> https://patches.dpdk.org/patch/75001/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F75001&data=02%7C01%7Clongli%40microsoft.com%7C1f1640e423394eb94f6e08d85a4ee081%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358642130122587&sdata=Y9OdJYjrfRA2uDr%2Bs%2FMyqmYFZjPwsXPWV%2BvYWVTSy04%3D&reserved=0>
>  . Ported this fix and was able to get rid of the seg fault, but now stuck at 
> another issue. When we are transmitting packets of size within 
> HN_TXCOPY_THRESHOLD we

Hi,

The patch mentioned is merged to the 18.11 branch in dpdk-stable repo
and part of 18.11.10-rc1, so expected to be in 18.11.10. ETA 28th September.

In case it's already fixed, you can try the 18.11.10-rc1 release. These
netvsc backports were added since 18.11.9. The corresponding dpdk main
commit id's are in the full log.

$ git log --oneline v18.11.9..HEAD .
363bdf0f49 net/netvsc: fix chimney index
5b3a327709 net/netvsc: fix crash during Tx
77cf88c0c6 net/netvsc: fix underflow when Rx external mbuf
592571 net/netvsc: do not spin forever waiting for reply

The list of fixes that were tagged for stable but not backported is
here:
http://inbox.dpdk.org/stable/20200901100115.72365-1-ktray...@redhat.com/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox.dpdk.org%2Fstable%2F20200901100115.72365-1-ktraynor%40redhat.com&data=02%7C01%7Clongli%40microsoft.com%7C1f1640e423394eb94f6e08d85a4ee081%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358642130132583&sdata=BkEMWpgwjXSKZaZTTr3XN1fGWzuwv3%2BEQQOxyzy0SEc%3D&reserved=0>

are all good but any larger packets/fragmented packets are getting
dropped after some time. As soon as we start to receive the transmit
completion event NVS_TYPE_RNDIS_ACK as failed, packets with size greater
than HN_TXCOPY_THRESHOLD starts to drop and never recovers. Packets less
than HN_TXCOPY

Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

Yes the patch solves the seg fault issue, but even after backporting the patch 
we are not able to send packets with size higher than 512. The packets not 
being transmitted is the real problem here. I have also tried to take the 
18.11.10rc1 build but faced similar issues in transmitting the packets.

--
Regards,
Souvik

From: dev  On Behalf Of Kevin Traynor
Sent: Wednesday, September 16, 2020 10:18 AM
To: Dey, Souvik ; dev@dpdk.org
Cc: Stephen Hemminger ; lon...@microsoft.com; 
Yigit, Ferruh ; sthem...@microsoft.com
Subject: Re: [dpdk-dev] Issue with net/netvsc pmd in 18.11.9


NOTICE: This email was received from an EXTERNAL sender


On 16/09/2020 13:00, Dey, Souvik wrote:
> Hi All,
> I updated from dpdk 18.11.6 to 18.11.9 and my netvsc pmd stopped working as 
> expected. Firstly, I saw a crash in tx packets as soon as the dpdk app comes 
> up. In doing some googling found a bug that was fixed after 18.11.9 
> https://patches.dpdk.org/patch/75001/<https://patches.dpdk.org/patch/75001> . 
> Ported this fix and was able to get rid of the seg fault, but now stuck at 
> another issue. When we are transmitting packets of size within 
> HN_TXCOPY_THRESHOLD we

Hi,

The patch mentioned is merged to the 18.11 branch in dpdk-stable repo
and part of 18.11.10-rc1, so expected to be in 18.11.10. ETA 28th September.

In case it's already fixed, you can try the 18.11.10-rc1 release. These
netvsc backports were added since 18.11.9. The corresponding dpdk main
commit id's are in the full log.

$ git log --oneline v18.11.9..HEAD .
363bdf0f49 net/netvsc: fix chimney index
5b3a327709 net/netvsc: fix crash during Tx
77cf88c0c6 net/netvsc: fix underflow when Rx external mbuf
592571 net/netvsc: do not spin forever waiting for reply

The list of fixes that were tagged for stable but not backported is
here:
http://inbox.dpdk.org/stable/20200901100115.72365-1-ktray...@redhat.com/<http://inbox.dpdk.org/stable/20200901100115.72365-1-ktray...@redhat.com>

are all good but any larger packets/fragmented packets are getting
dropped after some time. As soon as we start to receive the transmit
completion event NVS_TYPE_RNDIS_ACK as failed, packets with size greater
than HN_TXCOPY_THRESHOLD starts to drop and never recovers. Packets less
than HN_TXCOPY_THRESHOLD works properly there after though. Any idea why
this is happening and is there is some fix which is already there which
is done after 18.11.9 release ?

Maybe you can bisect the 18.11 branch to find where it stops working,
there is only ~10 netvsc commits between 18.11.6 and 18.11.9. The
release notes [1] or git history will tell you which commits are in
which releases. Bear in mind that some commits were rebased for 18.11,
so if you find the offending commit, you might want to check that it was
correctly backported too.

Kevin.

[1] 
http://doc.dpdk.org/guides-18.11/rel_notes/release_18_11.html<http://doc.dpdk.org/guides-18.11/rel_notes/release_18_11.html>

> We are at the critical part of our release, so any help in this regard will 
> be highly appreciated. Thanks in advance for all the help.
>
> PS: I also tried to put the net/netvsc: return the correct chimney index 
> <https://patches.dpdk.org/patch/75118/<https://patches.dpdk.org/patch/75118>> 
> fix in but nothing changed.
>
> --
> Regards,
> Souvik
>
> Log Snippet:
> I can see the below errors coming after some transmitting.
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
> hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
> hn_flush_txagg() tx: port 2:0 tx 2048 size 302
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 
> 1514
> hn_nvs_send_completed() tx: port 2:0 complete tx 429496729

[dpdk-dev] Issue with net/netvsc pmd in 18.11.9

[Dey, Souvik]

Hi All,
  I updated from dpdk 18.11.6 to 18.11.9 and my netvsc pmd stopped working 
as expected. Firstly, I saw a crash in tx packets as soon as the dpdk app comes 
up. In doing some googling found a bug that was fixed after 18.11.9 
https://patches.dpdk.org/patch/75001/ . Ported this fix and was able to get rid 
of the seg fault, but now stuck at another issue. When we are transmitting 
packets of size within HN_TXCOPY_THRESHOLD we are all good but any larger 
packets/fragmented packets are getting dropped after some time. As soon as we 
start to receive the transmit completion event NVS_TYPE_RNDIS_ACK as failed, 
packets with size greater than HN_TXCOPY_THRESHOLD starts to drop and never 
recovers. Packets less than HN_TXCOPY_THRESHOLD works properly there after 
though. Any idea why this is happening and is there is some fix which is 
already there which is done after 18.11.9 release ?
We are at the critical part of our release, so any help in this regard will be 
highly appreciated. Thanks in advance for all the help.

PS: I also tried to put the net/netvsc: return the correct chimney index 
  fix in but nothing changed.

--
Regards,
Souvik

Log Snippet:
I can see the below errors coming after some transmitting.
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_flush_txagg() tx: port 2:0 tx 2048 size 302
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 2048 packets 1 bytes 242

hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_flush_txagg() tx: port 2:0 tx 2624 size 302
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 packets 1 bytes 1514
hn_nvs_send_completed() tx: port 2:0 complete tx 2624 packets 1 bytes 242

hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 3 size 0
hn_xmit_sg() tx: port 2:0 tx 4294967295 segs 2 size 0
hn_flush_txagg() tx: port 2:0 tx 2688 size 302
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2
hn_nvs_send_completed() tx: port 2:0 complete tx 4294967295 failed status 2
hn_nvs_send_completed() tx: port 2:0 complete tx 42949672

Re: [dpdk-dev] [PATCH] net/i40e: issue with ADD VLAN from Guest

[Dey, Souvik]

Hi Zhang,
I have submitted this patch way back in April and I see the patch has been 
deferred. Is there any particular reason behind that. As I have not received 
any communication about that was just wondering if there is something wrong 
that I might have done in the patch submission process to cause this.
Thanks for your help.
--
Regards,
Souvik

-Original Message-
From: Dey, Souvik 
Sent: Tuesday, April 14, 2020 5:59 PM
To: beilei.x...@intel.com; qi.z.zh...@intel.com
Cc: dev@dpdk.org; Dey, Souvik 
Subject: [PATCH] net/i40e: issue with ADD VLAN from Guest

From: "Dey, Souvik" 

In case of i40evf pmd, when ADD_VLAN is sent down the linux i40e driver, along 
with add the vlan the kernel driver also enables the vlan stripping by default.
This might have issues if the app configured DEV_RX_OFFLOAD_VLAN_STRIP as off 
at the port configuration. The app after adding the VLAN will expect the VLAN 
to be coming in the received packets but, due to VLAN_STRIP enabled at the PF, 
it will get stripped.
This behavior of the Linux driver causes confussion with the DPDK app using 
i40e_pmd. So it is better to check the state of the DEV_RX_OFFLOAD_VLAN_STRIP 
flag in the dev_conf and disable the vlan strip after sending add_vlan if app 
configured the VLAN_STRIP as disabled.


Signed-off-by: Souvik Dey 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 244397e..b8b6c57 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1044,6 +1044,7 @@ i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid) 
 {
 struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
 struct virtchnl_vlan_filter_list *vlan_list;
+struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
 uint8_t cmd_buffer[sizeof(struct virtchnl_vlan_filter_list) +
 sizeof(uint16_t)];
 int err;
@@ -1060,8 +1061,21 @@ i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid)
 args.out_buffer = vf->aq_resp;
 args.out_size = I40E_AQ_BUF_SZ;
 err = i40evf_execute_vf_cmd(dev, &args);
-if (err)
+if (err) {
 PMD_DRV_LOG(ERR, "fail to execute command OP_ADD_VLAN");
+return ret;
+}
+/*
+ * In linux kernel driver on receiving ADD_VLAN it enables
+ * VLAN_STRIP by default. So disable it if app confifured
+ * it that way.
+ */
+if (!(dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP)) {
+err = i40evf_disable_vlan_strip(dev);
+if (err)
+PMD_DRV_LOG(ERR, "fail to execute command disable_vlan_strip "
+"as a part of OP_ADD_VLAN");
+}

 return err;
 }
--
2.9.3.windows.1

Re: [dpdk-dev] i40eVF pmd vlan id handling

[Dey, Souvik]

We need to enable DEV_RX_OFFLOAD_VLAN_FILTER from the DPDK app, and then 
configure the specific vlan id using rte_eth_dev_vlan_filter() to have vlan id 
come up to the guest. By default in VmWare I guess VLAN+MAC filtering gets 
enabled as, we set 0/4095 vlan_id on the VF to allow all Vlans. Can you check 
by setting the above offload and if that helps you .

--
Thanks,
Souvik

From: Yan Fridland 
Sent: Monday, June 15, 2020 8:34 AM
To: Dey, Souvik 
Subject: RE: i40eVF pmd vlan id handling


NOTICE: This email was received from an EXTERNAL sender


Hi Dey,

As I see in my tests with i40en on VMware, I don't have any issues when working 
with PF directly in Passthrough mode without SR-IOV. Problems start when 
working with VF (i40evf) and in my case I don't even try to do any offloading, 
but simply send a predefined tagged packet (tagged in application) to the port 
and I see that it's not even leaving the port. Its stuck somewhere between VF 
and PF. Perhaps you know what I should configure if I don't want HW offloading 
in VLAN handling and I want to tag by myself .. ?

Thanks
Yan

-Original Message-
From: users mailto:users-boun...@dpdk.org>> On Behalf 
Of Dey, Souvik
Sent: Monday, April 13, 2020 7:04 PM
To: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>; 
beilei.x...@intel.com<mailto:beilei.x...@intel.com>
Cc: ferruh.yi...@intel.com<mailto:ferruh.yi...@intel.com>; 
qi.z.zh...@intel.com<mailto:qi.z.zh...@intel.com>
Subject: [dpdk-users] i40eVF pmd vlan id handling

Hi All,
I am using DPDK 18.11.2 and i40e PF linux driver on the host 2.4.6. I see 
there, when I enable DEV_RX_OFFLOAD_VLAN_FILTER from the DPDK app, and then 
configure the specific vlan id using rte_eth_dev_vlan_filter(). As per DPDK 
code by default when we do dev_configure, we call i40evf_init_vlan() and if we 
don't enable rxmode.offloads with DEV_RX_OFFLOAD_VLAN_STRIP, then we should 
send VIRTCHNL_OP_DISABLE_VLAN_STRIPPING command to the PF from the guest.

With more debugging enabled, when DPDK requests VLAN filtering by sending 
VIRTCHNL_OP_ADD_VLAN to the PF, then we see that the VF stripping is enabled 
also on Linux. If we don't add VLAN ID and send VIRTCHNL_OP_ADD_VLAN message 
down to the PF , then we do receive packets with VLAN ID set.
The same works fine in VmWare drivers, where we do receive VALN id in the 
packets if STRIP is disabled.

In the linux case, when we receive frames with VLAN headers, the vlan id is 
stripped at the PF, and the TCI will record the missing VLAN details when 
handed up to the DPDK driver.

With i40e debug enabled, it's clear to see the difference being reported in 
i40e_rxd_to_vlan_tci:


Example using VLAN on i40evf SR-IOV (vlan fails):
PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 8, vlan_tci_outer: 0
Port 0 pkt-len=60 nb-segs=1
ETH: src=00:10:E0:8D:A7:52 dst=FF:FF:FF:FF:FF:FF type=0x0806
ARP: hrd=1 proto=0x0800 hln=6 pln=4 op=1 (ARP Request)
sha=00:10:E0:8D:A7:52 sip=8.8.8.102<http://8.8.8.102>
tha=00:00:00:00:00:00 tip=8.8.8.3<http://8.8.8.3>

As the application requested tagging not be stripped, and the hardware driver 
was not able to disable strip, in my opinion either DPDK or linux driver should 
have a bug in handing this. Also as we see VmWare i40e driver working it could 
be either a extra config required for linux driver or a bug in linux driver.
I also tried to add a call to rte_vlan_insert() to reinstate the VLAN header 
using the data from TCI in i40e_rxd_to_vlan_tci(), but it is having performance 
impacts as expected. Also as rte_vlan_insert() does not support QINQ, it will 
have other issues too.

Can you please clarify if this is working for i40e vlan filter test and if we 
are missing something in the DPDK, like sending 
VIRTCHNL_OP_DISABLE_VLAN_STRIPPING after every VIRTCHNL_OP_ADD_VLAN if 
DEV_RX_OFFLOAD_VLAN_STRIP is not set by the DPDk app.

--
Regards,
Souvik

Re: [dpdk-dev] i40eVF pmd vlan id handling

[Dey, Souvik]

Hi Beilei,
  Yes , as per our requirement, we need to have vlan stripped disabled, 
when we enable vlan filter and add vlan to the PF from the guest, so that the 
vlan id comes upto the app in the packet itself without striping. We also tried 
to call rte_vlan_insert in the packet receive side, but that has huge 
performance impacts.

What we do from the DPDK app, is during the port configuration, we enable 
vlan_filter and disable vlan_strip as a part of dev_conf.rxmode.offloads. Then, 
when we have vlans from the app to be added to the PF, we call add_vlan with 
the vlan id to be added.
As a part of the add_vlan, the kernel PF driver enables vlan_strip too by 
default. Now in this case we cannot use the vlan_offload_set from the DPDK to 
disable the vlan_strip.
As per the code in rte_eth_dev_set_vlan_offload() , in this case if we pass the 
mask as ETH_VLAN_FILTER_OFFLOAD, and both cur and org will evaluate to be 
equal(as DEV_RX_OFFLOAD_VLAN_STRIP is already disabled during port conf) and 
VLAN_STRIP will not be disabled.

  cur = !!(offload_mask & ETH_VLAN_STRIP_OFFLOAD);
  org = !!(dev_offloads & DEV_RX_OFFLOAD_VLAN_STRIP);
  if (cur != org) {
   if (cur)
 dev_offloads |= DEV_RX_OFFLOAD_VLAN_STRIP;
   else
 dev_offloads &= ~DEV_RX_OFFLOAD_VLAN_STRIP;
   mask |= ETH_VLAN_STRIP_MASK;
  }

The only possibility will be that we keep VLAN_STRIP enabled during port 
configuration and then call set_vlan_offload to disable the VLAN_STRIP, by 
passing the mask as ETH_VLAN_FILTER_OFFLOAD .
But this will also have issues, when we try to add the 2nd vlan_id. As the PF 
support till 8/16(depends on PF driver version) vlan ids from the guest(without 
trust mode on) , the 2nd add_vlan call will again enable the vlan_strip in the 
PF.
This will happen as after the 1st call to the set_vlan_offload, on successful 
vlan_offload_set() , we will update the dev_conf.rxmode.offloads with the 
computed dev_offloads (dev_offloads &= ~DEV_RX_OFFLOAD_VLAN_STRIP).
dev->data->dev_conf.rxmode.offloads = dev_offloads;

So, we will face the same issue as descried above where cur and org will 
evaluate to be equal(as VLAN_STRIP already disabled in 1st  call) and 
VLAN_STRIP will not be disabled again.

Instead of that, if we call i40evf_disable_vlan_strip() when 
dev_conf.rxmode.offloads has VLAN_STRIP set to disabled after successful call 
of add_vlan from the pmd itself that will help in every scenario.
This scenario works fine if we use DPDK at the PF side too as we don’t enable 
VLAN_STRIP in add_vlan in the DPDK i40e PF.

--
Regards,
Souvik

From: Xing, Beilei 
Sent: Tuesday, April 14, 2020 2:37 AM
To: Dey, Souvik ; dev@dpdk.org; us...@dpdk.org
Cc: Yigit, Ferruh ; Zhang, Qi Z 
Subject: RE: i40eVF pmd vlan id handling


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

With kernel PF + DPDK VF, enable vlan filter and disable vlan strip on VF side, 
is this your requirement?
If yes, I think you can do . vlan_offload_set after doing . vlan_filter_set on 
VF side.

BR,
Beilei

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Tuesday, April 14, 2020 4:04 AM
To: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>; 
Xing, Beilei mailto:beilei.x...@intel.com>>
Cc: Yigit, Ferruh mailto:ferruh.yi...@intel.com>>; 
Zhang, Qi Z mailto:qi.z.zh...@intel.com>>
Subject: RE: i40eVF pmd vlan id handling

On debugging further it looks like that linux driver enables vlan_striping by 
default when VIRTCHNL_OP_ADD_VLAN is sent to the PF.

static int i40e_vc_add_vlan_msg(struct i40e_vf *vf, u8 *msg)
{
  …..
  i40e_vlan_stripping_enable(vsi);
  ….
}

Due to this when ever we enable vlan on i40e the van is stripped by default 
while sending it to the Guest. This could be handled by the below patch in DPDK 
:
In file i40e_ethdev_vf.c
static int
i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid)
{
  struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
  struct virtchnl_vlan_filter_list *vlan_list;
  uint8_t cmd_buffer[sizeof(struct virtchnl_vlan_filter_list) +
  sizeof(uint16_t)];
  int err;
  struct vf_cmd_info args;

  vlan_list = (struct virtchnl_vlan_filter_list *)cmd_buffer;
  vlan_list->vsi_id = vf->vsi_res->vsi_id;
  vlan_list->num_elements = 1;
  vlan_list->vlan_id[0] = vlanid;

  args.ops = VIRTCHNL_OP_ADD_VLAN;
  args.in_args = (u8 *)&cmd_buffer;
  args.in_args_size = sizeof(cmd_buffer);
  args.out_buffer = vf->aq_resp;
  args.out_size = I40E_AQ_BUF_SZ;
  err = i40evf_execute_vf_cmd(dev, &args);
  if (err)
PMD_DRV_LOG(ERR, "fail to execute command OP_ADD_VLAN");
+ if (!(dev_conf->rxmode.offloads & DEV_R

Re: [dpdk-dev] i40eVF pmd vlan id handling

[Dey, Souvik]

On debugging further it looks like that linux driver enables vlan_striping by 
default when VIRTCHNL_OP_ADD_VLAN is sent to the PF.

static int i40e_vc_add_vlan_msg(struct i40e_vf *vf, u8 *msg)
{
  .
  i40e_vlan_stripping_enable(vsi);
  
}

Due to this when ever we enable vlan on i40e the van is stripped by default 
while sending it to the Guest. This could be handled by the below patch in DPDK 
:
In file i40e_ethdev_vf.c
static int
i40evf_add_vlan(struct rte_eth_dev *dev, uint16_t vlanid)
{
  struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
  struct virtchnl_vlan_filter_list *vlan_list;
  uint8_t cmd_buffer[sizeof(struct virtchnl_vlan_filter_list) +
  sizeof(uint16_t)];
  int err;
  struct vf_cmd_info args;

  vlan_list = (struct virtchnl_vlan_filter_list *)cmd_buffer;
  vlan_list->vsi_id = vf->vsi_res->vsi_id;
  vlan_list->num_elements = 1;
  vlan_list->vlan_id[0] = vlanid;

  args.ops = VIRTCHNL_OP_ADD_VLAN;
  args.in_args = (u8 *)&cmd_buffer;
  args.in_args_size = sizeof(cmd_buffer);
  args.out_buffer = vf->aq_resp;
  args.out_size = I40E_AQ_BUF_SZ;
  err = i40evf_execute_vf_cmd(dev, &args);
  if (err)
PMD_DRV_LOG(ERR, "fail to execute command OP_ADD_VLAN");
+ if (!(dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP)) {
+   i40evf_disable_vlan_strip(dev);
+ }
  return err;
}
Or we need to call . vlan_offload_set after doing . vlan_filter_set from the 
DPDK app ?

--
Regards,
Souvik

From: Dey, Souvik
Sent: Monday, April 13, 2020 12:04 PM
To: dev@dpdk.org; us...@dpdk.org; beilei.x...@intel.com
Cc: ferruh.yi...@intel.com; qi.z.zh...@intel.com
Subject: i40eVF pmd vlan id handling

Hi All,
I am using DPDK 18.11.2 and i40e PF linux driver on the host 2.4.6. I 
see there, when I enable DEV_RX_OFFLOAD_VLAN_FILTER from the DPDK app, and then 
configure the specific vlan id using rte_eth_dev_vlan_filter(). As per DPDK 
code by default when we do dev_configure, we call i40evf_init_vlan() and if we 
don't enable rxmode.offloads with DEV_RX_OFFLOAD_VLAN_STRIP, then we should 
send VIRTCHNL_OP_DISABLE_VLAN_STRIPPING command to the PF from the guest.

With more debugging enabled, when DPDK requests VLAN filtering by sending 
VIRTCHNL_OP_ADD_VLAN to the PF, then we see that the VF stripping is enabled 
also on Linux. If we don't add VLAN ID and send VIRTCHNL_OP_ADD_VLAN message 
down to the PF , then we do receive packets with VLAN ID set.

The same works fine in VmWare drivers, where we do receive VALN id in the 
packets if STRIP is disabled.

In the linux case, when we receive frames with VLAN headers, the vlan id is 
stripped at the PF, and the TCI will record the missing VLAN details when 
handed up to the DPDK driver.

With i40e debug enabled, it's clear to see the difference being reported in 
i40e_rxd_to_vlan_tci:


Example using VLAN on i40evf SR-IOV (vlan fails):
  PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 8, vlan_tci_outer: 0
  Port 0 pkt-len=60 nb-segs=1
ETH:  src=00:10:E0:8D:A7:52 dst=FF:FF:FF:FF:FF:FF type=0x0806
ARP:  hrd=1 proto=0x0800 hln=6 pln=4 op=1 (ARP Request)
  sha=00:10:E0:8D:A7:52 sip=8.8.8.102
  tha=00:00:00:00:00:00 tip=8.8.8.3

As the application requested tagging not be stripped, and the hardware driver 
was not able to disable strip, in my opinion either DPDK or linux driver should 
have a bug in handing this. Also as we see VmWare i40e driver working it could 
be either a extra config required for linux driver or a bug in linux driver.

I also tried to add a call to rte_vlan_insert() to reinstate the VLAN header 
using the data from TCI in i40e_rxd_to_vlan_tci(), but it is having performance 
impacts as expected. Also as rte_vlan_insert() does not support QINQ, it will 
have other issues too.

Can you please clarify if this is working for i40e vlan filter test and if we 
are missing something in the DPDK, like sending 
VIRTCHNL_OP_DISABLE_VLAN_STRIPPING after every VIRTCHNL_OP_ADD_VLAN if 
DEV_RX_OFFLOAD_VLAN_STRIP is not set by the DPDk app.

--
Regards,
Souvik

[dpdk-dev] i40eVF pmd vlan id handling

[Dey, Souvik]

Hi All,
I am using DPDK 18.11.2 and i40e PF linux driver on the host 2.4.6. I 
see there, when I enable DEV_RX_OFFLOAD_VLAN_FILTER from the DPDK app, and then 
configure the specific vlan id using rte_eth_dev_vlan_filter(). As per DPDK 
code by default when we do dev_configure, we call i40evf_init_vlan() and if we 
don't enable rxmode.offloads with DEV_RX_OFFLOAD_VLAN_STRIP, then we should 
send VIRTCHNL_OP_DISABLE_VLAN_STRIPPING command to the PF from the guest.

With more debugging enabled, when DPDK requests VLAN filtering by sending 
VIRTCHNL_OP_ADD_VLAN to the PF, then we see that the VF stripping is enabled 
also on Linux. If we don't add VLAN ID and send VIRTCHNL_OP_ADD_VLAN message 
down to the PF , then we do receive packets with VLAN ID set.
The same works fine in VmWare drivers, where we do receive VALN id in the 
packets if STRIP is disabled.

In the linux case, when we receive frames with VLAN headers, the vlan id is 
stripped at the PF, and the TCI will record the missing VLAN details when 
handed up to the DPDK driver.

With i40e debug enabled, it's clear to see the difference being reported in 
i40e_rxd_to_vlan_tci:


Example using VLAN on i40evf SR-IOV (vlan fails):
  PMD: i40e_rxd_to_vlan_tci(): Mbuf vlan_tci: 8, vlan_tci_outer: 0
  Port 0 pkt-len=60 nb-segs=1
ETH:  src=00:10:E0:8D:A7:52 dst=FF:FF:FF:FF:FF:FF type=0x0806
ARP:  hrd=1 proto=0x0800 hln=6 pln=4 op=1 (ARP Request)
  sha=00:10:E0:8D:A7:52 sip=8.8.8.102
  tha=00:00:00:00:00:00 tip=8.8.8.3

As the application requested tagging not be stripped, and the hardware driver 
was not able to disable strip, in my opinion either DPDK or linux driver should 
have a bug in handing this. Also as we see VmWare i40e driver working it could 
be either a extra config required for linux driver or a bug in linux driver.
I also tried to add a call to rte_vlan_insert() to reinstate the VLAN header 
using the data from TCI in i40e_rxd_to_vlan_tci(), but it is having performance 
impacts as expected. Also as rte_vlan_insert() does not support QINQ, it will 
have other issues too.

Can you please clarify if this is working for i40e vlan filter test and if we 
are missing something in the DPDK, like sending 
VIRTCHNL_OP_DISABLE_VLAN_STRIPPING after every VIRTCHNL_OP_ADD_VLAN if 
DEV_RX_OFFLOAD_VLAN_STRIP is not set by the DPDk app.

--
Regards,
Souvik

Re: [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case

[Dey, Souvik]

Just for reference also attached the changed patch in text format with the 
changes requested below. Have raised a v3 of the patch too.
Now bit ceckpatches and check-git-logs works fine and also updated vlan to VLAN.

--
Thanks,
Souvik


From: Jerin Jacob 
Sent: Sunday, April 5, 2020 9:06 AM
To: Dey, Souvik 
Cc: Rasesh Mody ; Shahed Shaikh ; 
Jerin Jacob Kollanukkaran ; ferruh.yi...@intel.com; 
tho...@monjalon.net; dev@dpdk.org; sta...@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case


NOTICE: This email was received from an EXTERNAL sender


On Thu, Mar 5, 2020 at 7:21 PM Dey, Souvik 
mailto:so...@rbbn.com>> wrote:
>
> Thanks will do that. And will also try to remove the trailer in the patches. 
> Thanks for pointing it out.
>
> From: dev mailto:dev-boun...@dpdk.org>> On Behalf Of 
> Rasesh Mody
> Sent: Tuesday, March 3, 2020 6:01 PM
> To: Dey, Souvik mailto:so...@rbbn.com>>; Shahed Shaikh 
> mailto:shsha...@marvell.com>>; Jerin Jacob 
> Kollanukkaran mailto:jer...@marvell.com>>; 
> ferruh.yi...@intel.com<mailto:ferruh.yi...@intel.com>; 
> tho...@monjalon.net<mailto:tho...@monjalon.net>
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>; sta...@dpdk.org<mailto:sta...@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV 
> case

1) Please change vlan to VLAN
2) Fix the following checkpatch issue. Probably move the new code to a
new function
to get enough space.

[master][dpdk-next-net-mrvl] $ ./devtools/checkpatches.sh

### net/bnx2x: handle guest VLAN for SR-IOV case

WARNING:BAD_SIGN_OFF: email address '"Dey Souvik" 
mailto:so...@rbbn.com>>'
might be better as 'Dey Souvik mailto:so...@rbbn.com>>'
#16:
Signed-off-by: "Dey Souvik" mailto:so...@rbbn.com>>

WARNING:LONG_LINE_COMMENT: line over 80 characters
#27: FILE: drivers/net/bnx2x/bnx2x.c:2219:
+ /* when transmitting in a vf, start bd must
hold the ethertype

WARNING:LONG_LINE: line over 80 characters
#36: FILE: drivers/net/bnx2x/bnx2x.c:2225:
+ if (eh->ether_type ==
rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {

WARNING:LONG_LINE: line over 80 characters
#41: FILE: drivers/net/bnx2x/bnx2x.c:2230:
+
ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);

WARNING:LONG_LINE: line over 80 characters
#47: FILE: drivers/net/bnx2x/bnx2x.c:2236:
+
(rte_be_to_cpu_16(eh->ether_type)));

WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal
patch author 'Dey, Souvik mailto:so...@rbbn.com>>'

total: 0 errors, 6 warnings, 0 checks, 28 lines checked

0/1 valid patch

[dpdk-dev] [PATCH v3] net/bnx2x: handle guest VLAN for SR-IOV case

[Dey, Souvik]

From: Souvik Dey 

In case of bnx2xvf pmd, tx packets can support vland id in 2 ways:
1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the
vlanid in mbuf->vlan_tci.
2. the tx packet itself has the vlan id included in the packet.
The first case is working as expected but the second case where
the vlan id is included in thetx packets itself was found not
working as expected. To handle that we need to properly set the
start_bd bitfield and the vlan_or_ethertype instead of setting it
to just the ethertype in case of VF.


Signed-off-by: Souvik Dey <"so...@rbbn.com>
---
v3:
 * Fixed the checkpatch issue.
 * Changed vlan to VLAN in the headline.
 
v2:
 * Fix compilation issues.
 * Changed the Subject Line as recommended.
 
 drivers/net/bnx2x/bnx2x.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 0b4030e..ff7646b 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2216,11 +2216,27 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct 
rte_mbuf *m0)
tx_start_bd->vlan_or_ethertype =
rte_cpu_to_le_16(pkt_prod);
else {
+   /* when transmitting in a vf, start bd
+* must hold the ethertype for fw to enforce it
+*/
struct rte_ether_hdr *eh =
rte_pktmbuf_mtod(m0, struct rte_ether_hdr *);
 
-   tx_start_bd->vlan_or_ethertype =
-   rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
+   /* Still need to consider inband vlan for enforced */
+   if (eh->ether_type ==
+   rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
+   struct rte_vlan_hdr *vh =
+   (struct rte_vlan_hdr *)(eh + 1);
+   tx_start_bd->bd_flags.as_bitfield |=
+   (X_ETH_INBAND_VLAN <<
+   ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
+   tx_start_bd->vlan_or_ethertype =
+   rte_cpu_to_le_16(ntohs(vh->vlan_tci));
+   } else {
+   tx_start_bd->vlan_or_ethertype =
+   (rte_cpu_to_le_16
+   (rte_be_to_cpu_16(eh->ether_type)));
+   }
}
}
 
-- 
2.9.3.windows.1

Re: [dpdk-dev] [EXT] [PATCH] net/bnx2x: add multicast MAC address filtering

[Dey, Souvik]

Hi All,

Yes I did. I am not getting the below errors.

sodey@SODEY-LMA MINGW64 ~/DPDK_Patch/patch
$ ../dpdk/devtools/checkpatches.sh 
v2-0001-net-bnx2x-add-multicast-MAC-address-filtering

1/1 valid patch

Also Fixed the Wrong tag issue with check-git-log.sh. Attached the patch in 
text format too as is asked for.

The Footer is added from the server side for us, I have tried to get that 
removed for all the mails to dpdk.org, do check and let me know if they are 
fine now. Do I need to repost the patch again or is the mail with the text 
format is enough.

--
Regards,
Souvik


From: Jerin Jacob 
Sent: Sunday, April 5, 2020 9:10 AM
To: Rasesh Mody 
Cc: Dey, Souvik ; Shahed Shaikh ; Jerin 
Jacob Kollanukkaran ; ferruh.yi...@intel.com; 
tho...@monjalon.net; dev@dpdk.org; sta...@dpdk.org
Subject: Re: [dpdk-dev] [EXT] [PATCH] net/bnx2x: add multicast MAC address 
filtering


NOTICE: This email was received from an EXTERNAL sender


On Wed, Mar 4, 2020 at 4:58 AM Rasesh Mody 
mailto:rm...@marvell.com>> wrote:
>
> Hi Souvik,
>
>
>
> Could you resend this patch in text format?
>
>
>
> When we are doing open source work, the contents of the footer are not 
> compatible with what we are doing. Please remove the footer in patches and 
> mailing list interactions for future.


Please fix the following issue as well.
1) [master][dpdk-next-net-mrvl] $ ./devtools/check-git-log.sh
Wrong tag:
Signed-off-by: "Dey, Souvik" mailto:so...@rbbn.com>>

Rasesh,
I will wait for your ack for merging this patch.

[dpdk-dev] support of kni ethtool for other drivers

[Dey, Souvik]

Hi All,
  Is there any plan to support ethtool for other drivers apart from 
igb/ixgbe for kni interfaes ?

--
Regards,
Souvik

Re: [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case

[Dey, Souvik]

Thanks will do that. And will also try to remove the trailer in the patches. 
Thanks for pointing it out.

From: dev  On Behalf Of Rasesh Mody
Sent: Tuesday, March 3, 2020 6:01 PM
To: Dey, Souvik ; Shahed Shaikh ; Jerin 
Jacob Kollanukkaran ; ferruh.yi...@intel.com; 
tho...@monjalon.net
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case


NOTICE: This email was received from an EXTERNAL sender


>From: dev mailto:dev-boun...@dpdk.org>> On Behalf Of 
>Dey, Souvik
>Sent: Monday, March 02, 2020 5:29 PM
>
>In case of bnx2xvf pmd, tx packets can support vland id in 2 ways :
>1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the vlanid in
>mbuf->vlan_tci.
>2. the tx packet itself has the vlan id included in the packet.
>The first case is working as expected but the second case where the vlan id is
>included in thetx packets itself was found not working as expected. To handle
>that we need to properly set the start_bd bitfield and the vlan_or_ethertype
>instead of setting it to just the ethertype in case of VF.
>
>
>Signed-off-by: "Dey, Souvik" mailto:so...@rbbn.com>>
>---

May be it would be good to use --in-reply-to when generating the patch and 
resubmit. This will ensure it lands up in the same thread as the first patch.
http://mails.dpdk.org/archives/test-report/2020-March/119108.html<http://mails.dpdk.org/archives/test-report/2020-March/119108.html>

Acked-by: Rasesh Mody mailto:rm...@marvell.com>>

>v2:
> * Fix compilation issues.
> * Changed the Subject Line as recommended.
>
>
> drivers/net/bnx2x/bnx2x.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c index
>0b4030e..0afa602 100644
>--- a/drivers/net/bnx2x/bnx2x.c
>+++ b/drivers/net/bnx2x/bnx2x.c
>@@ -2216,11 +2216,25 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
>struct rte_mbuf *m0)
> tx_start_bd->vlan_or_ethertype =
> rte_cpu_to_le_16(pkt_prod);
> else {
>+ /* when transmitting in a vf, start bd must hold the
>ethertype
>+ * for fw to enforce it
>+ */
> struct rte_ether_hdr *eh =
> rte_pktmbuf_mtod(m0, struct rte_ether_hdr *);
>-
>- tx_start_bd->vlan_or_ethertype =
>- rte_cpu_to_le_16(rte_be_to_cpu_16(eh-
>>ether_type));
>+ /* Still need to consider inband vlan for enforced */
>+ if (eh->ether_type ==
>rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
>+ struct rte_vlan_hdr *vh =
>+ (struct rte_vlan_hdr *)(eh + 1);
>+ tx_start_bd->bd_flags.as_bitfield |=
>+ (X_ETH_INBAND_VLAN <<
>+
> ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
>+ tx_start_bd->vlan_or_ethertype =
>+ rte_cpu_to_le_16(ntohs(vh-
>>vlan_tci));
>+ } else {
>+ tx_start_bd->vlan_or_ethertype =
>+ (rte_cpu_to_le_16
>+ (rte_be_to_cpu_16(eh-
>>ether_type)));
>+ }
> }
> }
>
>--
>2.9.3
>
>
>---
>
>Notice: This e-mail together with any attachments may contain information of
>Ribbon Communications Inc. that
>is confidential and/or proprietary for the sole use of the intended recipient.
>Any review, disclosure, reliance or
>distribution by others or forwarding without express permission is strictly
>prohibited. If you are not the intended
>recipient, please notify the sender immediately and then delete all copies,
>including any attachments.
>---
>

When we are doing open source work, the contents of above footer is not 
compatible with what we are doing. Please remove the footer in patches and 
mailing list interactions for future.


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

Re: [dpdk-dev] Issue with X550 link status

[Dey, Souvik]

Little more information. It looks like the below X550 nic is broken as the 
change related to http://patches.dpdk.org/patch/63951/ is not been backported.
The below patch broken the link status for ixgbevf and the fix was done in the 
above patch but we have only backported the below patch to 18.11.6 which breaks 
the ixgbevf link status. When is plan for 18.11.7 or updated 18.11.6 as we 
should not have a broken release.

--
Regads,
Souvik

From: Dey, Souvik
Sent: Wednesday, March 4, 2020 4:08 PM
To: dev@dpdk.org
Cc: xiaolong...@intel.com; xiao.zh...@intel.com; us...@dpdk.org; Stephen 
Hemminger ; Ferruh Yigit 
Subject: RE: Issue with X550 link status

The X550 NIC is of the below device id.
[root@stdell10 ~]# lspci -nnn | grep -i ether
19:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G 
X550T [8086:1563] (rev 01)
19:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G 
X550T [8086:1563] (rev 01)
19:10.0 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]
19:10.1 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]
19:10.2 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]
19:10.3 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]

So the mac_type is ixgbe_mac_X550_vf  in the below case.

--
Regards,
Souvik

From: Dey, Souvik
Sent: Wednesday, March 4, 2020 1:17 PM
To: dev@dpdk.org<mailto:dev@dpdk.org>
Cc: xiaolong...@intel.com<mailto:xiaolong...@intel.com>; 
xiao.zh...@intel.com<mailto:xiao.zh...@intel.com>; 
us...@dpdk.org<mailto:us...@dpdk.org>
Subject: Issue with X550 link status

Hi All,
  After upgrading to DPDK 18.11.6 LTS release from 18.11.2 the 
link_update call for link status update is not working for  X550 NICs SR-IOV 
enabled. On debugging it looks like the change introduced as a part of this 
patch is causing the issue.

https://patches.dpdk.org/patch/62140/

@@ -4135,6 +4138,10 @@  ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
  return rte_eth_linkstatus_set(dev, &link);
   }

+   esdp_reg = IXGBE_READ_REG(hw, IXGBE_ESDP);
+   if ((esdp_reg & IXGBE_ESDP_SDP3))
+  link_up = 0;
+
   if (link_up == 0) {
  if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
  intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;


I can see that the esdp_req is coming as 3735928495(0xDEADBEAF) and due to 
which the link_up is set to 0 even when ixgbevf_check_link returned link_up as 
1. Along with this patch I also see a path_fullchk patch introduced , does that 
play any role in this ?
Can someone please let me know if the patch has got some issues or it is 
behaving correctly and the link_status is failing for valid reason. As 
mentioned earlier the same HW with same NIC acting in SR-IOV works fine with 
18.11.2 DPDK . I am blocked at a customer bug dew to this and any urgent help 
will be much appreciated.

--
Regards,
Souvik


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

Re: [dpdk-dev] Issue with X550 link status

[Dey, Souvik]

The X550 NIC is of the below device id.
[root@stdell10 ~]# lspci -nnn | grep -i ether
19:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G 
X550T [8086:1563] (rev 01)
19:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G 
X550T [8086:1563] (rev 01)
19:10.0 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]
19:10.1 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]
19:10.2 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]
19:10.3 Ethernet controller [0200]: Intel Corporation X550 Virtual Function 
[8086:1565]

So the mac_type is ixgbe_mac_X550_vf  in the below case.

--
Regards,
Souvik

From: Dey, Souvik
Sent: Wednesday, March 4, 2020 1:17 PM
To: dev@dpdk.org
Cc: xiaolong...@intel.com; xiao.zh...@intel.com; us...@dpdk.org
Subject: Issue with X550 link status

Hi All,
  After upgrading to DPDK 18.11.6 LTS release from 18.11.2 the 
link_update call for link status update is not working for  X550 NICs SR-IOV 
enabled. On debugging it looks like the change introduced as a part of this 
patch is causing the issue.

https://patches.dpdk.org/patch/62140/

@@ -4135,6 +4138,10 @@  ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
  return rte_eth_linkstatus_set(dev, &link);
   }

+   esdp_reg = IXGBE_READ_REG(hw, IXGBE_ESDP);
+   if ((esdp_reg & IXGBE_ESDP_SDP3))
+  link_up = 0;
+
   if (link_up == 0) {
  if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
  intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;


I can see that the esdp_req is coming as 3735928495(0xDEADBEAF) and due to 
which the link_up is set to 0 even when ixgbevf_check_link returned link_up as 
1. Along with this patch I also see a path_fullchk patch introduced , does that 
play any role in this ?
Can someone please let me know if the patch has got some issues or it is 
behaving correctly and the link_status is failing for valid reason. As 
mentioned earlier the same HW with same NIC acting in SR-IOV works fine with 
18.11.2 DPDK . I am blocked at a customer bug dew to this and any urgent help 
will be much appreciated.

--
Regards,
Souvik


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

[dpdk-dev] Issue with X550 link status

[Dey, Souvik]

Hi All,
  After upgrading to DPDK 18.11.6 LTS release from 18.11.2 the 
link_update call for link status update is not working for  X550 NICs SR-IOV 
enabled. On debugging it looks like the change introduced as a part of this 
patch is causing the issue.

https://patches.dpdk.org/patch/62140/

@@ -4135,6 +4138,10 @@  ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
  return rte_eth_linkstatus_set(dev, &link);
   }
+   esdp_reg = IXGBE_READ_REG(hw, IXGBE_ESDP);
+   if ((esdp_reg & IXGBE_ESDP_SDP3))
+  link_up = 0;
+
   if (link_up == 0) {
  if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
  intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;


I can see that the esdp_req is coming as 3735928495(0xDEADBEAF) and due to 
which the link_up is set to 0 even when ixgbevf_check_link returned link_up as 
1. Along with this patch I also see a path_fullchk patch introduced , does that 
play any role in this ?
Can someone please let me know if the patch has got some issues or it is 
behaving correctly and the link_status is failing for valid reason. As 
mentioned earlier the same HW with same NIC acting in SR-IOV works fine with 
18.11.2 DPDK . I am blocked at a customer bug dew to this and any urgent help 
will be much appreciated.

--
Regards,
Souvik


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

[dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case

[Dey, Souvik]

In case of bnx2xvf pmd, tx packets can support vland id in 2 ways :
1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the
vlanid in mbuf->vlan_tci.
2. the tx packet itself has the vlan id included in the packet.
The first case is working as expected but the second case where
the vlan id is included in thetx packets itself was found not
working as expected. To handle that we need to properly set the
start_bd bitfield and the vlan_or_ethertype instead of setting it
to just the ethertype in case of VF.


Signed-off-by: "Dey, Souvik" 
---
v2:
 * Fix compilation issues.
 * Changed the Subject Line as recommended.
 

 drivers/net/bnx2x/bnx2x.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 0b4030e..0afa602 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2216,11 +2216,25 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct 
rte_mbuf *m0)
tx_start_bd->vlan_or_ethertype =
rte_cpu_to_le_16(pkt_prod);
else {
+   /* when transmitting in a vf, start bd must hold the 
ethertype
+* for fw to enforce it
+*/
struct rte_ether_hdr *eh =
rte_pktmbuf_mtod(m0, struct rte_ether_hdr *);
-
-   tx_start_bd->vlan_or_ethertype =
-   rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
+   /* Still need to consider inband vlan for enforced */
+   if (eh->ether_type == 
rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
+   struct rte_vlan_hdr *vh =
+   (struct rte_vlan_hdr *)(eh + 1);
+   tx_start_bd->bd_flags.as_bitfield |=
+   (X_ETH_INBAND_VLAN <<
+   
ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
+   tx_start_bd->vlan_or_ethertype =
+   rte_cpu_to_le_16(ntohs(vh->vlan_tci));
+   } else {
+   tx_start_bd->vlan_or_ethertype =
+   (rte_cpu_to_le_16
+   
(rte_be_to_cpu_16(eh->ether_type)));
+   }
}
}
 
-- 
2.9.3


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

[dpdk-dev] [PATCH] net/bnx2x: add multicast MAC address filtering

[Dey, Souvik]

Add support the set_mc_addr_list device operation in the bnx2xvf PMD.

The configured addresses are stored in the device private area, so
they can be flushed before adding new ones.
Without this v6 multicast packets were properly forwarded to the
Guest VF.



Signed-off-by: "Dey, Souvik" 
---
 drivers/net/bnx2x/bnx2x.h|  3 ++
 drivers/net/bnx2x/bnx2x_ethdev.c | 36 
 drivers/net/bnx2x/bnx2x_vfpf.c   | 59 
 drivers/net/bnx2x/bnx2x_vfpf.h   |  3 ++
 4 files changed, 101 insertions(+)

diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 1dbc981..3f9bb67 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1376,6 +1376,9 @@ struct bnx2x_softc {
uint8_t prio_to_cos[BNX2X_MAX_PRIORITY];
 
int panic;
+   /* Array of Multicast addrs */
+   struct rte_ether_addr mc_addrs[VF_MAX_MULTICAST_PER_VF];
+uint16_t mc_addrs_num; /* Multicast mac addresses number */
 }; /* struct bnx2x_softc */
 
 /* IOCTL sub-commands for edebug and firmware upgrade */
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 7864b5b..3ce9e7d 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -239,6 +239,10 @@ bnx2x_dev_start(struct rte_eth_dev *dev)
if (rte_intr_enable(&sc->pci_dev->intr_handle))
PMD_DRV_LOG(ERR, sc, "rte_intr_enable failed");
}
+   /* Configure the previously stored Multicast address list */
+   if (IS_VF(sc)) {
+bnx2x_vfpf_set_mcast(sc, sc->mc_addrs, sc->mc_addrs_num);
+}
 
bnx2x_dev_rxtx_init(dev);
 
@@ -266,6 +270,13 @@ bnx2x_dev_stop(struct rte_eth_dev *dev)
bnx2x_periodic_stop(dev);
}
 
+   /* Remove the configured Multicast list
+* Sending NULL for the list of address and the
+* Number is set to 0 denoting DEL_CMD */
+   if (IS_VF(sc)) {
+bnx2x_vfpf_set_mcast(sc, NULL, 0);
+}
+
ret = bnx2x_nic_unload(sc, UNLOAD_NORMAL, FALSE);
if (ret) {
PMD_DRV_LOG(DEBUG, sc, "bnx2x_nic_unload failed (%d)", ret);
@@ -349,6 +360,30 @@ bnx2x_dev_allmulticast_disable(struct rte_eth_dev *dev)
 }
 
 static int
+bnx2x_dev_set_mc_addr_list(struct rte_eth_dev *dev,
+   struct rte_ether_addr *mc_addrs, uint32_t mc_addrs_num)
+{
+struct bnx2x_softc *sc = dev->data->dev_private;
+int err;
+PMD_INIT_FUNC_TRACE(sc);
+/* flush previous addresses */
+err = bnx2x_vfpf_set_mcast(sc, NULL, 0);
+if (err)
+return err;
+sc->mc_addrs_num = 0;
+
+/* Add new ones */
+err = bnx2x_vfpf_set_mcast(sc, mc_addrs, mc_addrs_num );
+if (err)
+return err;
+
+sc->mc_addrs_num = mc_addrs_num;
+memcpy(sc->mc_addrs, mc_addrs, mc_addrs_num * sizeof(*mc_addrs));
+
+return 0;
+}
+
+static int
 bnx2x_dev_link_update(struct rte_eth_dev *dev, __rte_unused int 
wait_to_complete)
 {
struct bnx2x_softc *sc = dev->data->dev_private;
@@ -562,6 +597,7 @@ static const struct eth_dev_ops bnx2xvf_eth_dev_ops = {
.promiscuous_disable  = bnx2x_promisc_disable,
.allmulticast_enable  = bnx2x_dev_allmulticast_enable,
.allmulticast_disable = bnx2x_dev_allmulticast_disable,
+   .set_mc_addr_list = bnx2x_dev_set_mc_addr_list,
.link_update  = bnx2xvf_dev_link_update,
.stats_get= bnx2x_dev_stats_get,
.xstats_get   = bnx2x_dev_xstats_get,
diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 8f7559c..3bcc85d 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -703,3 +703,62 @@ bnx2x_vf_set_rx_mode(struct bnx2x_softc *sc)
 
return rc;
 }
+
+int
+bnx2x_vfpf_set_mcast(struct bnx2x_softc *sc,
+   struct rte_ether_addr *mc_addrs, 
uint32_t mc_addrs_num)
+{
+struct vf_set_q_filters_tlv *query;
+struct vf_common_reply_tlv *reply = &sc->vf2pf_mbox->resp.common_reply;
+int rc = 0;
+uint32_t i = 0;
+query = &sc->vf2pf_mbox->query[0].set_q_filters;
+bnx2x_vf_prep(sc, &query->first_tlv, BNX2X_VF_TLV_SET_Q_FILTERS,
+sizeof(*query));
+/* We support PFVF_MAX_MULTICAST_PER_VF mcast addresses tops */
+if (mc_addrs_num > VF_MAX_MULTICAST_PER_VF) {
+PMD_DRV_LOG(ERR, sc,
+   "VF supports not more than %d multicast MAC addresses",
+   VF_MAX_MULTICAST_PER_VF);
+
+rc = -EINVAL;
+goto out;
+}
+
+for (i = 0; i < mc_addrs_num; i++) {
+PMD_DRV_LOG(DEBUG, sc, "Adding mcast MAC:%x:%x:%x:%x:%x:%x",
+mc_addrs[i].addr_bytes[0],
+mc_addrs[i].addr_bytes[1],
+

[dpdk-dev] [PATCH v2] bnx2x: handle guest vlan for SR-IOV case

[Dey, Souvik]

In case of bnx2xvf pmd, tx packets can support vland id in 2 ways :
1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the
vlanid in mbuf->vlan_tci.
2. the tx packet itself has the vlan id included in the packet.
The first case is working as expected but the second case where
the vlan id is included in thetx packets itself was found not
working as expected. To handle that we need to properly set the
start_bd bitfield and the vlan_or_ethertype instead of setting it
to just the ethertype in case of VF.


Signed-off-by: "Dey, Souvik" 
---
v2:
 * Fix compilation issues.
   ether_type to rte_ether_type/
   ETHER_TYPE_VLAN to RTE_ETHER_TYPE_VLAN/
   vlan_hdr to rte_vlan_hdr/
 * Kept the Subject still same for refernce.

 drivers/net/bnx2x/bnx2x.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 0b4030e..6113d7c 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2216,11 +2216,23 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct 
rte_mbuf *m0)
tx_start_bd->vlan_or_ethertype =
rte_cpu_to_le_16(pkt_prod);
else {
+   /* when transmitting in a vf, start bd must hold the 
ethertype
+* for fw to enforce it
+*/
struct rte_ether_hdr *eh =
rte_pktmbuf_mtod(m0, struct rte_ether_hdr *);
-
-   tx_start_bd->vlan_or_ethertype =
-   rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
+   /* Still need to consider inband vlan for enforced */
+   if (eh->ether_type == 
rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
+   struct rte_vlan_hdr *vh = (struct vlan_hdr 
*)(eh + 1);
+   tx_start_bd->bd_flags.as_bitfield |=
+   (X_ETH_INBAND_VLAN <<
+   
ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
+   tx_start_bd->vlan_or_ethertype =
+   rte_cpu_to_le_16(ntohs(vh->vlan_tci));
+   } esle {
+   tx_start_bd->vlan_or_ethertype = 
(rte_cpu_to_le_16
+   (rte_be_to_cpu_16(eh->ether_type)));
+   }
}
}
 
-- 
2.9.3


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

[dpdk-dev] [PATCH v2] net/bnx2x: handle guest vlan for SR-IOV case

[Dey, Souvik]

In case of bnx2xvf pmd, tx packets can support vland id in 2 ways :
1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the
vlanid in mbuf->vlan_tci.
2. the tx packet itself has the vlan id included in the packet.
The first case is working as expected but the second case where
the vlan id is included in thetx packets itself was found not
working as expected. To handle that we need to properly set the
start_bd bitfield and the vlan_or_ethertype instead of setting it
to just the ethertype in case of VF.

Signed-off-by: "Dey, Souvik" 
---
v2:
* Fixed complitaion issues 
   ether_type  to rte_ether_type/
   ETHER_TYPE_VLAN to RTE_ETHER_TYPE_VLAN/
   vlan_hdr to rte_vlan_hdr/
* Changed the subject line from bnx2x to net/bnx2x.

 drivers/net/bnx2x/bnx2x.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index f7cca21..a96e8c2 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2219,11 +2219,11 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct 
rte_mbuf *m0)
/* when transmitting in a vf, start bd must hold the 
ethertype
 * for fw to enforce it
 */
-   struct ether_hdr *eh =
+   struct rte_ether_hdr  *eh =
rte_pktmbuf_mtod(m0, struct ether_hdr *);
/* Still need to consider inband vlan for enforced */
-   if (eh->ether_type == 
rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
-   struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 
1);
+   if (eh->ether_type == 
rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN)) {
+   struct rte_vlan_hdr *vh = (struct vlan_hdr 
*)(eh + 1);
tx_start_bd->bd_flags.as_bitfield |=
(X_ETH_INBAND_VLAN <<

ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
@@ -2231,7 +2231,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct 
rte_mbuf *m0)
rte_cpu_to_le_16(ntohs(vh->vlan_tci));
} else {
tx_start_bd->vlan_or_ethertype =
-   
rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
+   (rte_cpu_to_le_16(
+   
rte_be_to_cpu_16(eh->ether_type)));
}
}
}
-- 
2.9.3


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

[dpdk-dev] [PATCH] bnx2x: handle guest vlan for SR-IOV case

[Dey, Souvik]

In case of bnx2xvf pmd, tx packets can support vland id in 2 ways :
1. setting the mbuf ol_flags=PKT_TX_VLAN_PKT and passing the
vlanid in mbuf->vlan_tci.
2. the tx packet itself has the vlan id included in the packet.
The first case is working as expected but the second case where
the vlan id is included in thetx packets itself was found not
working as expected. To handle that we need to properly set the
start_bd bitfield and the vlan_or_ethertype instead of setting it
to just the ethertype in case of VF.

Signed-off-by: "Dey, Souvik" 
---
 drivers/net/bnx2x/bnx2x.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 0b4030e..f7cca21 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2216,11 +2216,23 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct 
rte_mbuf *m0)
tx_start_bd->vlan_or_ethertype =
rte_cpu_to_le_16(pkt_prod);
else {
-   struct rte_ether_hdr *eh =
-   rte_pktmbuf_mtod(m0, struct rte_ether_hdr *);
-
-   tx_start_bd->vlan_or_ethertype =
-   rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
+   /* when transmitting in a vf, start bd must hold the 
ethertype
+* for fw to enforce it
+*/
+   struct ether_hdr *eh =
+   rte_pktmbuf_mtod(m0, struct ether_hdr *);
+   /* Still need to consider inband vlan for enforced */
+   if (eh->ether_type == 
rte_cpu_to_be_16(ETHER_TYPE_VLAN)) {
+   struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 
1);
+   tx_start_bd->bd_flags.as_bitfield |=
+   (X_ETH_INBAND_VLAN <<
+   
ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
+   tx_start_bd->vlan_or_ethertype =
+   rte_cpu_to_le_16(ntohs(vh->vlan_tci));
+   } else {
+   tx_start_bd->vlan_or_ethertype =
+   
rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
+   }
}
}
 
-- 
2.9.3.windows.1


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

Re: [dpdk-dev] [PATCH v2] kni: fix possible kernel crash with va2pa

[Dey, Souvik]

Hi Yigit,
  I was facing the kernel crash issue, at skb_over_put(), using 
dpdk using 18.11 on 4.19.28 kernel. On checking I did find this  patch and this 
patch is solving the issue also. But then I saw you comment in the patch and 
that’s looks scary to have the patch. Is there any improvements/fixes planned 
for this issue and in which version? is there any performance impact of the 
below patch ? As this issues is blocking our release any inputs to this asap 
will be really appreciated.

--
Regards,
Souvik

From: dev  On Behalf Of Ferruh Yigit
Sent: Friday, March 22, 2019 4:49 PM
To: Yangchao Zhou ; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] kni: fix possible kernel crash with va2pa


NOTICE: This email was received from an EXTERNAL sender


On 3/12/2019 9:22 AM, Yangchao Zhou wrote:
> va2pa depends on the physical address and virtual address offset of
> current mbuf. It may get the wrong physical address of next mbuf which
> allocated in another hugepage segment.
>
> In rte_mempool_populate_default(), trying to allocate whole block of
> contiguous memory could be failed. Then, it would reserve memory in
> several memzones that have different physical address and virtual address
> offsets. The rte_mempool_populate_default() is used by
> rte_pktmbuf_pool_create().
>
> Signed-off-by: Yangchao Zhou mailto:zhouya...@gmail.com>>
> ---
> v2: Add an explanation that causes this problem.
> Use m->next to store physical address.

<...>

> @@ -481,7 +486,7 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
> uint32_t ret;
> uint32_t len;
> uint32_t i, num_rq, num_fq, num;
> - struct rte_kni_mbuf *kva;
> + struct rte_kni_mbuf *kva, *_kva;
> void *data_kva;
> struct sk_buff *skb;
> struct net_device *dev = kni->net_dev;
> @@ -545,8 +550,11 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
> if (!kva->next)
> break;
>
> - kva = pa2kva(va2pa(kva->next, kva));
> + _kva = kva;
> + kva = pa2kva(kva->next);
> data_kva = kva2data_kva(kva);
> + /* Convert physical address to virtual address */
> + _kva->next = pa2va(_kva->next, kva);
> }
> }
>

Also need to update 'kni_net_rx_lo_fifo()', at worst to update 'next' fields
because it fills 'kni->free_q', without conversion userspace will crash.

<...>

> @@ -550,7 +563,7 @@ rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf 
> **mbufs, unsigned num)
> unsigned int i;
>
> for (i = 0; i < num; i++)
> - phy_mbufs[i] = va2pa(mbufs[i]);
> + phy_mbufs[i] = va2pa_all(mbufs[i]);
>
> ret = kni_fifo_put(kni->rx_q, phy_mbufs, num);

There is a problem here.

When fifo 'kni->rx_q' is full, 'rte_kni_tx_burst' will send less mbuf than
requested, than the application needs to handle the remaining packages, most
probably will free them, but now some packages has physical address in their
'next' field, which will cause app to crash.

I don't know really how to solve this.
Perhaps getting free count from 'kni->rx_q' and only convert that much
(va2pa_all) to physical address can work, but I can't estimate performance
effect of it.


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

Re: [dpdk-dev] [PATCH] kni: fix possible kernel crash with va2pa

[Dey, Souvik]

Was there any update to this patch , I am also seeing kernel crash in 
kni_net_rx_normal dueing skb_put which is happening for chained mbufs.

--
Regards,
Souvik


From: dev  On Behalf Of Ferruh Yigit
Sent: Wednesday, March 6, 2019 12:31 PM
To: Yangchao Zhou ; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] kni: fix possible kernel crash with va2pa


NOTICE: This email was received from an EXTERNAL sender


On 2/28/2019 7:30 AM, Yangchao Zhou wrote:
> va2pa depends on the physical address and virtual address offset of
> current mbuf. It may get the wrong physical address of next mbuf which
> allocated in another hugepage segment.

Hi Yangchao,

The problem you described seems valid, when current mbuf and the mbuf pointed bu
next pointer from different (huge)pages, address calculation will be wrong.

Can you able to reproduce the issue, or recognized the problem theoretically?

>
> Signed-off-by: Yangchao Zhou mailto:zhouya...@gmail.com>>
> ---
> kernel/linux/kni/kni_net.c | 16 ++--
> .../eal/include/exec-env/rte_kni_common.h | 4 
> lib/librte_kni/rte_kni.c | 15 ++-
> 3 files changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
> index 7371b6d58..caef8754f 100644
> --- a/kernel/linux/kni/kni_net.c
> +++ b/kernel/linux/kni/kni_net.c
> @@ -61,18 +61,6 @@ kva2data_kva(struct rte_kni_mbuf *m)
> return phys_to_virt(m->buf_physaddr + m->data_off);
> }
>
> -/* virtual address to physical address */
> -static void *
> -va2pa(void *va, struct rte_kni_mbuf *m)
> -{
> - void *pa;
> -
> - pa = (void *)((unsigned long)va -
> - ((unsigned long)m->buf_addr -
> - (unsigned long)m->buf_physaddr));
> - return pa;
> -}
> -
> /*
> * It can be called to process the request.
> */
> @@ -363,7 +351,7 @@ kni_net_rx_normal(struct kni_dev *kni)
> if (!kva->next)
> break;
>
> - kva = pa2kva(va2pa(kva->next, kva));
> + kva = pa2kva(kva->next_pa);
> data_kva = kva2data_kva(kva);
> }
> }
> @@ -545,7 +533,7 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
> if (!kva->next)
> break;
>
> - kva = pa2kva(va2pa(kva->next, kva));
> + kva = pa2kva(kva->next_pa);
> data_kva = kva2data_kva(kva);
> }
> }
> diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h 
> b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> index 5afa08713..608f5c13f 100644
> --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> @@ -87,6 +87,10 @@ struct rte_kni_mbuf {
> char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_MIN_SIZE)));
> void *pool;
> void *next;
> + union {
> + uint64_t tx_offload;
> + void *next_pa; /**< Physical address of next mbuf. */
> + };

This will cause overwrite the 'tx_offload' via 'next_pa', we don't use
tx_offload in KNI but not sure about removing potential use for future.

What do you think about converting 'm->next' to physical address before putting
them into 'rx_q', and in kernel side after data copied to skb convert 'm->next'
back to virtual address before putting it into 'free_q' ?
I think both address conversion can be possible to do, a little tricky because
address conversion should be calculated in next mbuf and previous mbuf->next in
the chain should be updated.

> };
>
> /*
> diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
> index 73aef..1aaebcfa1 100644
> --- a/lib/librte_kni/rte_kni.c
> +++ b/lib/librte_kni/rte_kni.c
> @@ -353,6 +353,17 @@ va2pa(struct rte_mbuf *m)
> (unsigned long)m->buf_iova));
> }
>
> +static void *
> +va2pa_all(struct rte_mbuf *m)
> +{
> + struct rte_kni_mbuf *mbuf = (struct rte_kni_mbuf *)m;
> + while (mbuf->next) {
> + mbuf->next_pa = va2pa(mbuf->next);
> + mbuf = mbuf->next;
> + }
> + return va2pa(m);
> +}
> +
> static void
> obj_free(struct rte_mempool *mp __rte_unused, void *opaque, void *obj,
> unsigned obj_idx __rte_unused)
> @@ -550,7 +561,7 @@ rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf 
> **mbufs, unsigned num)
> unsigned int i;
>
> for (i = 0; i < num; i++)
> - phy_mbufs[i] = va2pa(mbufs[i]);
> + phy_mbufs[i] = va2pa_all(mbufs[i]);
>
> ret = kni_fifo_put(kni->rx_q, phy_mbufs, num);
>
> @@ -607,6 +618,8 @@ kni_allocate_mbufs(struct rte_kni *kni)
> offsetof(struct rte_kni_mbuf, pkt_len));
> RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, ol_flags) !=
> offsetof(struct rte_kni_mbuf, ol_flags));
> + RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, tx_offload) !=
> + offsetof(struct rte_kni_mbuf, tx_offload));
>
> /* Check if pktmbuf pool has been configured */
> if (kni->pktmbuf_pool == NULL) {
>


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, d

[dpdk-dev] kernel crash with DPDK 18.11

[Dey, Souvik]

Hi All,
  I am using DPDK 18.11 with linux kernel 4.19.28. I have kni 
devices created and I can see a crash in the kernel with ipv6/v4 fragmented 
packets. Does anyone seen this already or is there any fixes/patches available 
for this .

Snippet of kernel panic


Message from syslogd@vsbc1 at Jun 14 04:52:05 ...

kernel:[ 6815.672497] rte_kni: kni_net_rx_normal
kernel:[ 6815.672497] skbuff: skb_over_panic: text:24f44e9b len:3024 
put:1518 head:2a1b576a data:cec907b4 tail:0xc12 end:0x980 
dev:

Message from syslogd@vsbc1 at Jun 14 04:52:05 ...
kernel:[ 6815.672497] skbuff: skb_over_panic: text:24f44e9b len:3024 
put:1518 head:2a1b576a data:cec907b4 tail:0xc12 end:0x980 
dev:

Message from syslogd@vsbc1 at Jun 14 04:52:06 ...
kernel:[ 6815.854134] Kernel panic - not syncing: Fatal exception

Message from syslogd@vsbc1 at Jun 14 04:52:06 ...
kernel:[ 6815.854134] Kernel panic - not syncing: Fatal exception
--
Regards,
Souvik


---
Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  
Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly 
prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, 
including any attachments.
---

Re: [dpdk-dev] [dpdk-users] i40e VF PMD not getting multicast packets

[Dey, Souvik]

Hi Xing/Wu,
I am using dpdk 17.11.2 and i40e kernel driver 2.4.6, and I see 
all multocast packets are not reaching the VF. Do we support/tested i40evf pmd 
for v6 support ? Can you please let me know what we need to do extra to make v6 
work with i40evf pmd. V4 works fine. I also have rte_eth_allmulticast_enable() 
enabled but without any success.

--
Regards,
Souvik

From: Dey, Souvik
Sent: Tuesday, October 16, 2018 11:06 AM
To: Ruinan Hu ; Ruinan 
Cc: dev@dpdk.org; us...@dpdk.org
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets

Hi Ruinan,
In that case, do we say that v6 will not work at all i40evf pmd 
till trust mode is on ? Yes I do agree that I am able to see the error in the 
dmesg on the host
“kernel: i40e :83:00.3: Unprivileged VF 1 is attempting to configure 
promiscuous mode” , when trust mode is off, but with trust mode on also we are 
not able to get multicast packets up to the VM. The same works fine with linux 
i40evf, where the VF is receiving all the multicast packets for V6 ICMPv6 NS .

Any suggestion on what can be required to make v6 multicast work with i40evf ?

Note: I don’t think vanilla linux driver (i40evf) is using promiscuous mode to 
receive multicast packets.

--
Regards,
Souvik

From: Ruinan Hu mailto:ruinan...@casa-systems.com>>
Sent: Monday, October 15, 2018 3:36 PM
To: Dey, Souvik mailto:so...@rbbn.com>>; Ruinan 
mailto:hurui...@gmail.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets


NOTICE: This email was received from an EXTERNAL sender


When you set the allmulticast or promiscuous from dpdk, host rejects the 
request if trust bit it off. You can see the error message from dmesg. I don’t 
know why your kernel i40evf works.

-Ruinan Hu

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Monday, October 15, 2018 3:27 PM
To: Ruinan mailto:hurui...@gmail.com>>; Ruinan Hu 
mailto:ruinan...@casa-systems.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets

Moreover I wanted to mention one more thing, that the issue of multicast 
packets not working is only with DPDK 140eVF PMD. In case I use the i40evf of 
the kernel then it is working fine and I don’t see any issues with v6. So why 
is the trust mode a requirement for DPDK pmd ?

From: Dey, Souvik
Sent: Monday, October 15, 2018 2:52 PM
To: Ruinan mailto:hurui...@gmail.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets

No the trust mode is off currently on the host. I can try with trust mode on 
too. But I have a doubt, is trust mode mandatory to be turned on to make the VF 
receive v6 multicast packets ? if yes then how will this work in openstack 
(i40e VF dpdk) with v6 ?

--
Regards,
Souvik

From: Ruinan mailto:hurui...@gmail.com>>
Sent: Monday, October 15, 2018 2:33 PM
To: Dey, Souvik mailto:so...@rbbn.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: Re: [dpdk-users] i40e VF PMD not getting multicast packets


NOTICE: This email was received from an EXTERNAL sender


Hi,

Did you enable trust mode on vf? If trust is off on host, promiscuous can’t 
enabled from vm.

Ruinan Hu
ruinan...@casa-systems.com<mailto:ruinan...@casa-systems.com>
(857) 209-1955

> On Oct 15, 2018, at 14:26, Dey, Souvik 
> mailto:so...@rbbn.com>> wrote:
>
> Hi All,
> I am currently facing issues with getting the multicast IPv6 packets when 
> using the i40evf pmd.
>
> I do see there is a limitation mentioned in the release notes of DPDK that
>
> 16.27. I40e VF may not receive packets in the promiscuous mode
> Description:
> Promiscuous mode is not supported by the DPDK i40e VF driver when using the 
> i40e Linux kernel driver as host driver.
> Implication:
> The i40e VF does not receive packets when the destination MAC address is 
> unknown.
> Resolution/Workaround:
> Use a explicit destination MAC address that matches the VF.
> Affected Environment/Platform:
> All.
> Driver/Module:
> Poll Mode Driver (PMD).
>
>
> Do this mean that multicast promiscuous mode is also not supported ? I am 
> currently facing issues with receiving packets multicast packets for IPv6 
> which is making IPv6 to fail with i40evf pmd.
> I am currently using 17.11.2 DPDK with the Centos 7.5 and i40e 2.4.6 version 
> on the host. I have the rte_eth_allmulticast_enable() also set for the port 
> but still I see all multicast packets are not reaching the pmd.
> Also if promiscuous mode has to be turned off then how should we add 
> multicast address to the PF from the VF ?
> --
> Regards,
> Souvik

Re: [dpdk-dev] [dpdk-users] i40e VF PMD not getting multicast packets

[Dey, Souvik]

Hi Ruinan,
In that case, do we say that v6 will not work at all i40evf pmd 
till trust mode is on ? Yes I do agree that I am able to see the error in the 
dmesg on the host
“kernel: i40e :83:00.3: Unprivileged VF 1 is attempting to configure 
promiscuous mode” , when trust mode is off, but with trust mode on also we are 
not able to get multicast packets up to the VM. The same works fine with linux 
i40evf, where the VF is receiving all the multicast packets for V6 ICMPv6 NS .

Any suggestion on what can be required to make v6 multicast work with i40evf ?

Note: I don’t think vanilla linux driver (i40evf) is using promiscuous mode to 
receive multicast packets.

--
Regards,
Souvik

From: Ruinan Hu 
Sent: Monday, October 15, 2018 3:36 PM
To: Dey, Souvik ; Ruinan 
Cc: dev@dpdk.org; us...@dpdk.org
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets


NOTICE: This email was received from an EXTERNAL sender


When you set the allmulticast or promiscuous from dpdk, host rejects the 
request if trust bit it off. You can see the error message from dmesg. I don’t 
know why your kernel i40evf works.

-Ruinan Hu

From: Dey, Souvik mailto:so...@rbbn.com>>
Sent: Monday, October 15, 2018 3:27 PM
To: Ruinan mailto:hurui...@gmail.com>>; Ruinan Hu 
mailto:ruinan...@casa-systems.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets

Moreover I wanted to mention one more thing, that the issue of multicast 
packets not working is only with DPDK 140eVF PMD. In case I use the i40evf of 
the kernel then it is working fine and I don’t see any issues with v6. So why 
is the trust mode a requirement for DPDK pmd ?

From: Dey, Souvik
Sent: Monday, October 15, 2018 2:52 PM
To: Ruinan mailto:hurui...@gmail.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets

No the trust mode is off currently on the host. I can try with trust mode on 
too. But I have a doubt, is trust mode mandatory to be turned on to make the VF 
receive v6 multicast packets ? if yes then how will this work in openstack 
(i40e VF dpdk) with v6 ?

--
Regards,
Souvik

From: Ruinan mailto:hurui...@gmail.com>>
Sent: Monday, October 15, 2018 2:33 PM
To: Dey, Souvik mailto:so...@rbbn.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: Re: [dpdk-users] i40e VF PMD not getting multicast packets


NOTICE: This email was received from an EXTERNAL sender


Hi,

Did you enable trust mode on vf? If trust is off on host, promiscuous can’t 
enabled from vm.

Ruinan Hu
ruinan...@casa-systems.com<mailto:ruinan...@casa-systems.com>
(857) 209-1955

> On Oct 15, 2018, at 14:26, Dey, Souvik 
> mailto:so...@rbbn.com>> wrote:
>
> Hi All,
> I am currently facing issues with getting the multicast IPv6 packets when 
> using the i40evf pmd.
>
> I do see there is a limitation mentioned in the release notes of DPDK that
>
> 16.27. I40e VF may not receive packets in the promiscuous mode
> Description:
> Promiscuous mode is not supported by the DPDK i40e VF driver when using the 
> i40e Linux kernel driver as host driver.
> Implication:
> The i40e VF does not receive packets when the destination MAC address is 
> unknown.
> Resolution/Workaround:
> Use a explicit destination MAC address that matches the VF.
> Affected Environment/Platform:
> All.
> Driver/Module:
> Poll Mode Driver (PMD).
>
>
> Do this mean that multicast promiscuous mode is also not supported ? I am 
> currently facing issues with receiving packets multicast packets for IPv6 
> which is making IPv6 to fail with i40evf pmd.
> I am currently using 17.11.2 DPDK with the Centos 7.5 and i40e 2.4.6 version 
> on the host. I have the rte_eth_allmulticast_enable() also set for the port 
> but still I see all multicast packets are not reaching the pmd.
> Also if promiscuous mode has to be turned off then how should we add 
> multicast address to the PF from the VF ?
> --
> Regards,
> Souvik

Re: [dpdk-dev] [dpdk-users] i40e VF PMD not getting multicast packets

[Dey, Souvik]

Moreover I wanted to mention one more thing, that the issue of multicast 
packets not working is only with DPDK 140eVF PMD. In case I use the i40evf of 
the kernel then it is working fine and I don’t see any issues with v6. So why 
is the trust mode a requirement for DPDK pmd ?

From: Dey, Souvik
Sent: Monday, October 15, 2018 2:52 PM
To: Ruinan 
Cc: dev@dpdk.org; us...@dpdk.org
Subject: RE: [dpdk-users] i40e VF PMD not getting multicast packets

No the trust mode is off currently on the host. I can try with trust mode on 
too. But I have a doubt, is trust mode mandatory to be turned on to make the VF 
receive v6 multicast packets ? if yes then how will this work in openstack 
(i40e VF dpdk) with v6 ?

--
Regards,
Souvik

From: Ruinan mailto:hurui...@gmail.com>>
Sent: Monday, October 15, 2018 2:33 PM
To: Dey, Souvik mailto:so...@rbbn.com>>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; us...@dpdk.org<mailto:us...@dpdk.org>
Subject: Re: [dpdk-users] i40e VF PMD not getting multicast packets


NOTICE: This email was received from an EXTERNAL sender


Hi,

Did you enable trust mode on vf? If trust is off on host, promiscuous can’t 
enabled from vm.

Ruinan Hu
ruinan...@casa-systems.com<mailto:ruinan...@casa-systems.com>
(857) 209-1955

> On Oct 15, 2018, at 14:26, Dey, Souvik 
> mailto:so...@rbbn.com>> wrote:
>
> Hi All,
> I am currently facing issues with getting the multicast IPv6 packets when 
> using the i40evf pmd.
>
> I do see there is a limitation mentioned in the release notes of DPDK that
>
> 16.27. I40e VF may not receive packets in the promiscuous mode
> Description:
> Promiscuous mode is not supported by the DPDK i40e VF driver when using the 
> i40e Linux kernel driver as host driver.
> Implication:
> The i40e VF does not receive packets when the destination MAC address is 
> unknown.
> Resolution/Workaround:
> Use a explicit destination MAC address that matches the VF.
> Affected Environment/Platform:
> All.
> Driver/Module:
> Poll Mode Driver (PMD).
>
>
> Do this mean that multicast promiscuous mode is also not supported ? I am 
> currently facing issues with receiving packets multicast packets for IPv6 
> which is making IPv6 to fail with i40evf pmd.
> I am currently using 17.11.2 DPDK with the Centos 7.5 and i40e 2.4.6 version 
> on the host. I have the rte_eth_allmulticast_enable() also set for the port 
> but still I see all multicast packets are not reaching the pmd.
> Also if promiscuous mode has to be turned off then how should we add 
> multicast address to the PF from the VF ?
> --
> Regards,
> Souvik

Re: [dpdk-dev] [dpdk-users] i40e VF PMD not getting multicast packets

[Dey, Souvik]

No the trust mode is off currently on the host. I can try with trust mode on 
too. But I have a doubt, is trust mode mandatory to be turned on to make the VF 
receive v6 multicast packets ? if yes then how will this work in openstack 
(i40e VF dpdk) with v6 ?

--
Regards,
Souvik

From: Ruinan 
Sent: Monday, October 15, 2018 2:33 PM
To: Dey, Souvik 
Cc: dev@dpdk.org; us...@dpdk.org
Subject: Re: [dpdk-users] i40e VF PMD not getting multicast packets


NOTICE: This email was received from an EXTERNAL sender


Hi,

Did you enable trust mode on vf? If trust is off on host, promiscuous can’t 
enabled from vm.

Ruinan Hu
ruinan...@casa-systems.com<mailto:ruinan...@casa-systems.com>
(857) 209-1955

> On Oct 15, 2018, at 14:26, Dey, Souvik 
> mailto:so...@rbbn.com>> wrote:
>
> Hi All,
> I am currently facing issues with getting the multicast IPv6 packets when 
> using the i40evf pmd.
>
> I do see there is a limitation mentioned in the release notes of DPDK that
>
> 16.27. I40e VF may not receive packets in the promiscuous mode
> Description:
> Promiscuous mode is not supported by the DPDK i40e VF driver when using the 
> i40e Linux kernel driver as host driver.
> Implication:
> The i40e VF does not receive packets when the destination MAC address is 
> unknown.
> Resolution/Workaround:
> Use a explicit destination MAC address that matches the VF.
> Affected Environment/Platform:
> All.
> Driver/Module:
> Poll Mode Driver (PMD).
>
>
> Do this mean that multicast promiscuous mode is also not supported ? I am 
> currently facing issues with receiving packets multicast packets for IPv6 
> which is making IPv6 to fail with i40evf pmd.
> I am currently using 17.11.2 DPDK with the Centos 7.5 and i40e 2.4.6 version 
> on the host. I have the rte_eth_allmulticast_enable() also set for the port 
> but still I see all multicast packets are not reaching the pmd.
> Also if promiscuous mode has to be turned off then how should we add 
> multicast address to the PF from the VF ?
> --
> Regards,
> Souvik

[dpdk-dev] i40e VF PMD not getting multicast packets

[Dey, Souvik]

Hi All,
I am currently facing issues with getting the multicast IPv6 
packets when using the i40evf pmd.

I do see there is a limitation mentioned in the release notes of DPDK that

16.27. I40e VF may not receive packets in the promiscuous mode
Description:
Promiscuous mode is not supported by the DPDK i40e VF driver when using the 
i40e Linux kernel driver as host driver.
Implication:
The i40e VF does not receive packets when the destination MAC address is 
unknown.
Resolution/Workaround:
Use a explicit destination MAC address that matches the VF.
Affected Environment/Platform:
All.
Driver/Module:
Poll Mode Driver (PMD).


Do this mean that multicast promiscuous mode is also not supported ? I am 
currently facing issues with receiving packets multicast packets for IPv6 which 
is making IPv6 to fail with i40evf pmd.
I am currently using 17.11.2 DPDK with the Centos 7.5 and i40e 2.4.6 version on 
the host. I have the rte_eth_allmulticast_enable() also set for the port but 
still I see all multicast packets are not reaching the pmd.
Also if promiscuous mode has to be turned off then how should we add multicast 
address to the PF from the VF ?
--
Regards,
Souvik

Re: [dpdk-dev] I40evf VLAN stripping disable

[Dey, Souvik]

Hi Xing,
Do we need to do i40evf_add_vlan() to get the vlan packets up 
to the VM like we had in ixgbe_vf?  I see that if I have the vlan added through 
i40evf_add_vlan(), then the packet is received with the vlan stripped even if 
the vlan_strip is disabled in the PF. If I just do vlan_strip disabled and then 
send vlan packets it is all coming up to the VM. But is that not security issue 
as all VLANs even if not configured will be coming up to the VM, which never 
happened in the ixgbe case. I only have rte_eth_allmulticast_enable in my app , 
so expect that unicast/broadcast promisc mode is disabled by default.

--
Regard,
Souvik

From: Xing, Beilei [mailto:beilei.x...@intel.com]
Sent: Monday, June 11, 2018 3:58 AM
To: Dey, Souvik ; Wu, Jingjing ; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: RE: I40evf VLAN stripping disable


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

Could you try with kernel driver (version 2.4.3) first? In my environment, 
disable vlan strip in DPDK works with kernel driver version 2.4.3.

My test steps with testpmd:
>set fwd rxonly
>set verbose 1
>set promisc 0 off
>vlan set strip off 0
Then send a vlan packet with VF mac address.

Best Regards,
Beilei Xing

From: Dey, Souvik [mailto:so...@rbbn.com]
Sent: Friday, June 8, 2018 11:22 PM
To: Xing, Beilei mailto:beilei.x...@intel.com>>; Wu, 
Jingjing mailto:jingjing...@intel.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Cc: us...@dpdk.org<mailto:us...@dpdk.org>
Subject: I40evf VLAN stripping disable

Hi i40e/i40evf maintainers,

I was testing VLANs with i40evf pmd and is hitting the below issue.

I have the following configuration:
- host runs with Linux pf i40e driver(version 2.4.6)
- guest runs with DPDK 17.11.2 vf i40e driver

When I am sending a vlan packet from the outside to the guest, on the guest, I 
receive the packet which has the PKT_RX_VLAN_STRIPPED flag set although I'm not 
asking for it.
Even though my DPDK app has the rte_eth_conf.rxmode.hw_vlan_strip set to 0 and 
also verified that the 
i40evf_disable_vlan_strip(VIRTCHNL_OP_DISABLE_VLAN_STRIPPING) function is 
getting called and not returning any error from the linux pf driver.
Is this the default behavior that the VLAN will be always stripped by the PF 
irrespective of the setting ? Should the DPDK version take care of the 
re-adding the tag back to the packet in case hw_vlan_strip is disabled ? What 
should be best way of handling it ? Is it a bug in DPDK or I am missing 
something here.

I do see in the linux i40evf driver we are insert vlan header in the received 
packets in some cases.

--
Regards,
Souvik

[dpdk-dev] I40evf VLAN stripping disable

[Dey, Souvik]

Hi i40e/i40evf maintainers,

I was testing VLANs with i40evf pmd and is hitting the below issue.

I have the following configuration:
- host runs with Linux pf i40e driver(version 2.4.6)
- guest runs with DPDK 17.11.2 vf i40e driver
When I am sending a vlan packet from the outside to the guest, on the guest, I 
receive the packet which has the PKT_RX_VLAN_STRIPPED flag set although I'm not 
asking for it.
Even though my DPDK app has the rte_eth_conf.rxmode.hw_vlan_strip set to 0 and 
also verified that the 
i40evf_disable_vlan_strip(VIRTCHNL_OP_DISABLE_VLAN_STRIPPING) function is 
getting called and not returning any error from the linux pf driver.
Is this the default behavior that the VLAN will be always stripped by the PF 
irrespective of the setting ? Should the DPDK version take care of the 
re-adding the tag back to the packet in case hw_vlan_strip is disabled ? What 
should be best way of handling it ? Is it a bug in DPDK or I am missing 
something here.

I do see in the linux i40evf driver we are insert vlan header in the received 
packets in some cases.

--
Regards,
Souvik

[dpdk-dev] Reset of VF link in IXGBE

[Dey, Souvik]

Hi All,
  I see few patches in the DPDK regarding "Implement device reset 
on VF" and also "support reset of VF link" but I am not sure which version of 
DPDK is having the changes. Are they at all upstreamed or they are still under 
discussion. I am currently using DPDK 16.11, and facing issues with PF link up 
down due to this missing patch. Is there are plan to update 16.11 also with 
this patch set ?
Any help in this regarding will be very helpful.

--
Regards,
Souvik

Re: [dpdk-dev] [PATCH v1] drivers/net/ena: Copy PCI info to rte_eth_dev

[Dey, Souvik]

Hi Yigit,
I was testing with 16.11.2 dpdk version did found that few data were 
missing in the rte_eth_dev like the driver.name. Then tried to update my stream 
and check the handling and found the same missing. So raised the below patch. 
Now on double checking it looks like my pull from master failed and due to that 
I missed the below flow. 
 Yes, I cross checked and all the data is getting populated properly in the 
rte_eth_dev structure from the rte_pci_device. The below is not needed any more 
and can be removed. 
Thanks for pointing it out.

--
Regards,
Souvik


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
Sent: Tuesday, January 16, 2018 2:17 PM
To: Dey, Souvik ; j...@semihalf.com; j...@semihalf.com; 
neta...@amazon.com; evge...@amazon.com
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] drivers/net/ena: Copy PCI info to rte_eth_dev

On 1/16/2018 7:06 PM, so...@rbbn.com wrote:
> From: Souvik Dey 
> 
> We need to add the pci_dev info to the rte_eth_dev structure during 
> the eth_ena_dev_init. Informantions like driver_name and numa_node 
> will not be populated otherwise.

stacktrace is like:

eth_ena_pci_probe
  rte_eth_dev_pci_generic_probe
rte_eth_dev_pci_allocate
  rte_eth_copy_pci_info
eth_ena_dev_init

So, before eth_ena_dev_init() called,  rte_eth_copy_pci_info() already should 
be called and eth_dev updated with pci_dev info. And you shouldn't need this 
patch.

Do you observe any missing data in eth_dev?

> 
> Signed-off-by: Souvik Dey 
> 
> ---
> 
>  drivers/net/ena/ena_ethdev.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ena/ena_ethdev.c 
> b/drivers/net/ena/ena_ethdev.c index ac0803d..329cb29 100644
> --- a/drivers/net/ena/ena_ethdev.c
> +++ b/drivers/net/ena/ena_ethdev.c
> @@ -1270,6 +1270,8 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
>pci_dev->addr.devid,
>pci_dev->addr.function);
>  
> + rte_eth_copy_pci_info(eth_dev, pci_dev);
> +
>   adapter->regs = pci_dev->mem_resource[ENA_REGS_BAR].addr;
>   adapter->dev_mem_base = pci_dev->mem_resource[ENA_MEM_BAR].addr;
>  
> 

[dpdk-dev] Getting PF link status to DPDK-VF in case of SR-IOV

[Dey, Souvik]

Hi Ferruh/Lu,
I see that both of you have posted multiple patches in DPDK wrt 
IXGBE SR-IOV and PF to VF link status/ I am trying to use DPDK 16.11 and do see 
that it has the support of both pinging VF when PF link status changes and also 
VF support of mailbox msg when PF link is up/down. My question is that once the 
mailbox msg IXGBE_PF_CONTROL_MSG is received from the PF into the DPDK-VF is 
there any way to get the actual status of the link too as we get it in case of 
RTE_ETH_EVENT_INTR_LSC. I do understand that we need to reset the VF link 
whenever the link status change happens but along with that do we also need to 
reconfigure the vlans/mc_addrs configured on the PF from the VF ? As I am 
having kni interfaces mapped to the DPDK-VF it will be good to set the proper 
link status for them too if we can come to know about the PF status. Can you 
please suggest then best way of doing so ?
Also how dpdk bonding in ative backup mode will switch link, if port status of 
the PF is not known ?

--
Regards,
Souvik

[dpdk-dev] Hyper-V PMD in DPDK

[Dey, Souvik]

Hi All,
Do we have the Hyper-V DPDK PMD available now in 17.05 release. 
I don't see the drivers present. Can someone update me on the status of the 
same and if it already there in any active DPDK release ?

--
Regards,
Souvik

Re: [dpdk-dev] Query on VM_BUS and HyperV PMD

[Dey, Souvik]

Ok thanks. 

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Wednesday, April 5, 2017 12:10 AM
To: Dey, Souvik 
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Query on VM_BUS and HyperV PMD

On Wed, Apr 05, 2017 at 03:23:36AM +, Dey, Souvik wrote:
> Hi All,
>   As DPDK 16.11 is an LTS release is there any plans to backport 
> the VM-BUS and HyperV PMD from 17.05 to 16.11.

The generic rule is we don't backport features to a LTS release. Thus, the 
answer is no.

--yliu

[dpdk-dev] Query on VM_BUS and HyperV PMD

[Dey, Souvik]

Hi All,
  As DPDK 16.11 is an LTS release is there any plans to backport 
the VM-BUS and HyperV PMD from 17.05 to 16.11.
--
Regards,
Souvik

[dpdk-dev] Getting crash in rte_pktmbuf_alloc with 16.11 DPDK

[Dey, Souvik]

Hi ,
  I am trying to do rte_pktmbuf_alloc from a mempool within a 
secondary process after doing a rte_mempool_lookup for the same mempool. But 
the rte_pktmbuf_alloc crashes with the below backtrace

#0  0x in ?? ()
#1  0x00423da2 in rte_mempool_ops_dequeue_bulk (n=1, 
obj_table=0x7fffd8e0, mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/dist
#2  __mempool_generic_get (flags=, cache=, 
n=, obj_table=, mp=)
at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1296
#3  rte_mempool_generic_get (flags=, cache=, 
n=, obj_table=, mp=)
at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1334
#4  rte_mempool_get_bulk (n=1, obj_table=0x7fffd8e0, mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp
#5  rte_mempool_get (obj_p=0x7fffd8e0, mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/r
#6  rte_mbuf_raw_alloc (mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:761
#7  rte_pktmbuf_alloc (mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:1046

>From the trace it looks like that the ops->dequeue is failing as the ops is 
>not set properly.
In the primary process I have done a rte_mempool_create with the flags passed 
as 0 (indicating mp_mc option). This should have taken care of setting the ops 
properly. Also the rte_pktmbuf_alloc calls in the primary does not give any 
issues.
Both the primary and secondary DPDK app code was working fine with 2.1 DPDK, 
but now when I am trying to link to the newer DPDK versions like 16.07/16.11, 
it is crashing. There is no changes done in the app code.
I do see that the complete rte_mempool code has been changed between 2.1 to 
16.07 but could not  find any obvious reasons of the crash. Is my usage wrong 
or do we need to pass any new flag to make this work.

Did anyone faced similar issue or any help in this will be great for my 
debugging. Thanks in advance for the help.

--
Regards,
Souvik

[dpdk-dev] Getting crash in rte_pktmbuf_alloc with 16.11 DPDK

[Dey, Souvik]

Hi ,
  I am trying to do rte_pktmbuf_alloc from a mempool within a 
secondary process after doing a rte_mempool_lookup for the same mempool. But 
the rte_pktmbuf_alloc crashes with the below backtrace

#0  0x in ?? ()
#1  0x00423da2 in rte_mempool_ops_dequeue_bulk (n=1, 
obj_table=0x7fffd8e0, mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/dist
#2  __mempool_generic_get (flags=, cache=, 
n=, obj_table=, mp=)
at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1296
#3  rte_mempool_generic_get (flags=, cache=, 
n=, obj_table=, mp=)
at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1334
#4  rte_mempool_get_bulk (n=1, obj_table=0x7fffd8e0, mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp
#5  rte_mempool_get (obj_p=0x7fffd8e0, mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/r
#6  rte_mbuf_raw_alloc (mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:761
#7  rte_pktmbuf_alloc (mp=0x7fe910fbd540) at 
/sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:1046

>From the trace it looks like that the ops->dequeue is failing as the ops is 
>not set properly.
In the primary process I have done a rte_mempool_create with the flags passed 
as 0 (indicating mp_mc option). This should have taken care of setting the ops 
properly. Also the rte_pktmbuf_alloc calls in the primary does not give any 
issues.
Both the primary and secondary DPDK app code was working fine with 2.1 DPDK, 
but now when I am trying to link to the newer DPDK versions like 16.07/16.11, 
it is crashing. There is no changes done in the app code.
I do see that the complete rte_mempool code has been changed between 2.1 to 
16.07 but could not  find any obvious reasons of the crash. Is my usage wrong 
or do we need to pass any new flag to make this work.

Did anyone faced similar issue or any help in this will be great for my 
debugging. Thanks in advance for the help.

--
Regards,
Souvik

Re: [dpdk-dev] ixgbevf: support multicast packets from PF to VF

[Dey, Souvik]

Hi Wenzhuo,
Now I am using rte_eth_dev_set_mc_addr_list to configure the PF 
with the list of mc_addr supported by the VF, but interestingly only 1 of the 
mc_addr works and for other mc_addr packets does not even come up to the 
VF/DPDK PMD.

PMD: ixgbe_update_mc_addr_list_vf(): ixgbe_update_mc_addr_list_vf
PMD: ixgbe_update_mc_addr_list_vf(): MC Addr Count = 5
PMD: ixgbe_mta_vector(): MC Addr0  = 0,MC Addr1  = 1,mc_filter_type =0
PMD: ixgbe_update_mc_addr_list_vf(): Hash value = 0x010
PMD: ixgbe_mta_vector(): MC Addr0  = 0,MC Addr1  = 33,mc_filter_type =0
PMD: ixgbe_update_mc_addr_list_vf(): Hash value = 0x210
PMD: ixgbe_mta_vector(): MC Addr0  = 0,MC Addr1  = 213,mc_filter_type =0
PMD: ixgbe_update_mc_addr_list_vf(): Hash value = 0xD50
PMD: ixgbe_mta_vector(): MC Addr0  = 0,MC Addr1  = 14,mc_filter_type =0
PMD: ixgbe_update_mc_addr_list_vf(): Hash value = 0x0E0
PMD: ixgbe_mta_vector(): MC Addr0  = 0,MC Addr1  = 78,mc_filter_type =0
PMD: ixgbe_update_mc_addr_list_vf(): Hash value = 0x4E0

In the above list only  the mc_aadr hash D50 works and the other 2 in RED fails 
to receive any multicast packets. Is there any other setting or reconfiguration 
that is required to be done (both in DPDK or on PF) to get this working all the 
configured MC_ADDRs ?

I am using 2.1 DPDK on the guest and kernel 4.4 ixgbe PF drivers on the host .

--
Regards,
Souvik

From: Lu, Wenzhuo [mailto:wenzhuo...@intel.com]
Sent: Monday, December 5, 2016 6:35 PM
To: Dey, Souvik ; dev@dpdk.org
Cc: Dai, Wei 
Subject: RE: ixgbevf: support multicast packets from PF to VF

Hi Dey,
I'm confused.
rte_eth_allmulticast_enable means the port can receive all the multicast 
packets. In another word, it's multicast promiscuous mode.
rte_eth_dev_set_mc_addr_list means adding a series of multicast addresses to 
the filter, so the port can receive these specific multicast packets. It's not 
promiscuous.
During your test, I think only rte_eth_dev_set_mc_addr_list is working. 
rte_eth_allmulticast_enable has no effect.
As you mentioned the PF driver version, I'm afraid the problem is the PF.  When 
you call rte_eth_allmulticast_enable on VF, VF only sends a message to PF. PF 
need to take action. So you must have a PF which can support this feature.

From: Dey, Souvik [mailto:so...@sonusnet.com]
Sent: Tuesday, December 6, 2016 3:01 AM
To: Lu, Wenzhuo mailto:wenzhuo...@intel.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: ixgbevf: support multicast packets from PF to VF

Hi Wenzhuo,

There is nothing set with the rte_eth_dev_set_mc_addr_list and we are trying to 
receive the NS packet which has the destination MAC set as 33 33 ff 00 00 14. 
Also what I saw is that the handling of allmulticast_enable message in the 
kernel has happened after 4.0 version and the PF drivers which earlier kernel 
version will not support this. How should handle those scenarios ?

In my case too I tried 2 experiments :

1.  Only set the rte_eth_allmulticast_enable from the DPDK app and I 
patched the ixgbevf_pmd with our patch. The function was returning SUCCESS but 
the NS packets were received in the application.

2.  Then along with rte_eth_allmulticast_enable, I used the 
rte_eth_dev_set_mc_addr_list to set the MAC 33 33 ff 00 00 14 from my app to 
the pmd. After this I was successfully receiving the NS packets. But then the 
bigger question is how to automate the addition of mc_addr in 
rte_eth_dev_set_mc_addr_list as in the kni we are currently not using the 
kni_net_set_rx_mode() function which is called by the net_device whenever the 
new mc_addr is assigned to the net_device.


--
Regards,
Souvik

From: Lu, Wenzhuo [mailto:wenzhuo...@intel.com]
Sent: Sunday, December 4, 2016 9:02 PM
To: Dey, Souvik mailto:so...@sonusnet.com>>; 
dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: ixgbevf: support multicast packets from PF to VF

Hi Souvik,
To my opinion, rte_eth_dev_set_mc_addr_list has nothing to do with 
rte_eth_allmulticast_enable. rte_eth_allmulticast_enable is enough for the 
multicast packets.
I'm curious about the 1, what MAC addresses are set by 
rte_eth_dev_set_mc_addr_list? 2, What multicast packets are sent?
Thanks.



Best regards
Wenzhuo Lu

From: Dey, Souvik [mailto:so...@sonusnet.com]
Sent: Saturday, December 3, 2016 1:28 AM
To: dev@dpdk.org<mailto:dev@dpdk.org>; Lu, Wenzhuo
Subject: RE: ixgbevf: support multicast packets from PF to VF

Adding wenzhuo...@intel.com<mailto:wenzhuo...@intel.com>

From: Dey, Souvik
Sent: Friday, December 2, 2016 12:27 PM
To: 'dev@dpdk.org' mailto:dev@dpdk.org>>
Subject: ixgbevf: support multicast packets from PF to VF

Hi All,
I am trying to support multicast packet over SRIOV using kernel 
PF + DPDK VF(ixgbevf) drivers for ipv6. I am currently using 2.1 DPDK and found 
that there was a patch in 16.04 for "ixgbe: support multicast promiscuous mode 
on VF". So I have backported the patch to the

Re: [dpdk-dev] ixgbevf: support multicast packets from PF to VF

[Dey, Souvik]

Hi Wenzhuo,

There is nothing set with the rte_eth_dev_set_mc_addr_list and we are trying to 
receive the NS packet which has the destination MAC set as 33 33 ff 00 00 14. 
Also what I saw is that the handling of allmulticast_enable message in the 
kernel has happened after 4.0 version and the PF drivers which earlier kernel 
version will not support this. How should handle those scenarios ?

In my case too I tried 2 experiments :

1.   Only set the rte_eth_allmulticast_enable from the DPDK app and I 
patched the ixgbevf_pmd with our patch. The function was returning SUCCESS but 
the NS packets were received in the application.

2.   Then along with rte_eth_allmulticast_enable, I used the 
rte_eth_dev_set_mc_addr_list to set the MAC 33 33 ff 00 00 14 from my app to 
the pmd. After this I was successfully receiving the NS packets. But then the 
bigger question is how to automate the addition of mc_addr in 
rte_eth_dev_set_mc_addr_list as in the kni we are currently not using the 
kni_net_set_rx_mode() function which is called by the net_device whenever the 
new mc_addr is assigned to the net_device.


--
Regards,
Souvik

From: Lu, Wenzhuo [mailto:wenzhuo...@intel.com]
Sent: Sunday, December 4, 2016 9:02 PM
To: Dey, Souvik ; dev@dpdk.org
Subject: RE: ixgbevf: support multicast packets from PF to VF

Hi Souvik,
To my opinion, rte_eth_dev_set_mc_addr_list has nothing to do with 
rte_eth_allmulticast_enable. rte_eth_allmulticast_enable is enough for the 
multicast packets.
I'm curious about the 1, what MAC addresses are set by 
rte_eth_dev_set_mc_addr_list? 2, What multicast packets are sent?
Thanks.



Best regards
Wenzhuo Lu

From: Dey, Souvik [mailto:so...@sonusnet.com]
Sent: Saturday, December 3, 2016 1:28 AM
To: dev@dpdk.org<mailto:dev@dpdk.org>; Lu, Wenzhuo
Subject: RE: ixgbevf: support multicast packets from PF to VF

Adding wenzhuo...@intel.com<mailto:wenzhuo...@intel.com>

From: Dey, Souvik
Sent: Friday, December 2, 2016 12:27 PM
To: 'dev@dpdk.org' mailto:dev@dpdk.org>>
Subject: ixgbevf: support multicast packets from PF to VF

Hi All,
I am trying to support multicast packet over SRIOV using kernel 
PF + DPDK VF(ixgbevf) drivers for ipv6. I am currently using 2.1 DPDK and found 
that there was a patch in 16.04 for "ixgbe: support multicast promiscuous mode 
on VF". So I have backported the patch to the 2.1 DPDK but still multicast 
packets were not coming up to the DPDK app. Then I tried to enable the 
rte_eth_dev_set_mc_addr_list and with the the packets were coming up properly. 
Now I have some doubts :


1.  Do we have to use both rte_eth_dev_set_mc_addr_list and 
rte_eth_allmulticast_enable to get the multicast packets.

2.  How do we get the mc_addr_list dynamically as I don't see we are using 
the kni_net_set_rx_mode in rte_kni. Without this the DPDK app will not have any 
idea to update the mc_addr_list in the PF.

3.  Is there any other patches which I should be using to get this 
functionality working.

I am using : DPDK -2.1
Host kernel - 4.4 ( ubuntu)
Guest kernel - 3.2 (Debian)
Drivers - ixgbe ( for both pf and vf).


Thanks in advance for the help and support.

--
Regards,
Souvik

Re: [dpdk-dev] ixgbevf: support multicast packets from PF to VF

[Dey, Souvik]

Adding wenzhuo...@intel.com<mailto:wenzhuo...@intel.com>

From: Dey, Souvik
Sent: Friday, December 2, 2016 12:27 PM
To: 'dev@dpdk.org' 
Subject: ixgbevf: support multicast packets from PF to VF

Hi All,
I am trying to support multicast packet over SRIOV using kernel 
PF + DPDK VF(ixgbevf) drivers for ipv6. I am currently using 2.1 DPDK and found 
that there was a patch in 16.04 for "ixgbe: support multicast promiscuous mode 
on VF". So I have backported the patch to the 2.1 DPDK but still multicast 
packets were not coming up to the DPDK app. Then I tried to enable the 
rte_eth_dev_set_mc_addr_list and with the the packets were coming up properly. 
Now I have some doubts :


1.   Do we have to use both rte_eth_dev_set_mc_addr_list and 
rte_eth_allmulticast_enable to get the multicast packets.

2.   How do we get the mc_addr_list dynamically as I don't see we are using 
the kni_net_set_rx_mode in rte_kni. Without this the DPDK app will not have any 
idea to update the mc_addr_list in the PF.

3.   Is there any other patches which I should be using to get this 
functionality working.

I am using : DPDK -2.1
Host kernel - 4.4 ( ubuntu)
Guest kernel - 3.2 (Debian)
Drivers - ixgbe ( for both pf and vf).


Thanks in advance for the help and support.

--
Regards,
Souvik

[dpdk-dev] ixgbevf: support multicast packets from PF to VF

[Dey, Souvik]

Hi All,
I am trying to support multicast packet over SRIOV using kernel 
PF + DPDK VF(ixgbevf) drivers for ipv6. I am currently using 2.1 DPDK and found 
that there was a patch in 16.04 for "ixgbe: support multicast promiscuous mode 
on VF". So I have backported the patch to the 2.1 DPDK but still multicast 
packets were not coming up to the DPDK app. Then I tried to enable the 
rte_eth_dev_set_mc_addr_list and with the the packets were coming up properly. 
Now I have some doubts :


1.   Do we have to use both rte_eth_dev_set_mc_addr_list and 
rte_eth_allmulticast_enable to get the multicast packets.

2.   How do we get the mc_addr_list dynamically as I don't see we are using 
the kni_net_set_rx_mode in rte_kni. Without this the DPDK app will not have any 
idea to update the mc_addr_list in the PF.

3.   Is there any other patches which I should be using to get this 
functionality working.

I am using : DPDK -2.1
Host kernel - 4.4 ( ubuntu)
Guest kernel - 3.2 (Debian)
Drivers - ixgbe ( for both pf and vf).


Thanks in advance for the help and support.

--
Regards,
Souvik

[dpdk-dev] [PATCH v7] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi Stephen,
  As I am new to this patch submission, I did not get what you 
exactly meant my ?Please merge?, do you mean that you Ack the patch and it can 
be upstreamed or you want me submit a new version or something. Sorry for my 
ignorance.
Thanks

--
Souvik

From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: Thursday, October 6, 2016 6:30 PM
To: Kavanagh, Mark B 
Cc: Dey, Souvik ; yuanhan.liu at linux.intel.com; dev at 
dpdk.org
Subject: Re: [PATCH v7] net/virtio: add set_mtu in virtio

I think current patch is fine. If someone has later problem with it on some 
scenario we can fix the bug then.
Please merge

[dpdk-dev] [PATCH v7] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi Stephen/Liu,
   Any other comments or suggestions for this. If the below patch looks 
fine then please do suggest the next steps .

--
Regards,
Souvik

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dey, Souvik
Sent: Wednesday, October 5, 2016 10:05 AM
To: Kavanagh, Mark B ; yuanhan.liu at 
linux.intel.com; stephen at networkplumber.org
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v7] net/virtio: add set_mtu in virtio

Yes Mark, I have modified the patch with the below comments.

drivers/net/virtio/virtio_ethdev.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 423c597..1dbfea6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");  } 

+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */
+
+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
+   struct virtio_hw *hw = dev->data->dev_private;
+   uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
+   hw->vtnet_hdr_size;
+   uint32_t frame_size = mtu + ether_hdr_len;
+
+   if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
+   ETHER_MIN_MTU, (VIRTIO_MAX_RX_PKTLEN - ether_hdr_len));
+   return -EINVAL;
+   }
+   return 0;
+}

Let mem know if this looks good or we have few more comments. 

--
Regards,
Souvik

-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Wednesday, October 5, 2016 4:16 AM
To: Dey, Souvik ; yuanhan.liu at linux.intel.com; 
stephen at networkplumber.org
Cc: dev at dpdk.org
Subject: RE: [PATCH v7] net/virtio: add set_mtu in virtio

>Hi All,
>   Is there any further comments or modifications required for this 
>patch, or what next steps do you guys suggest here ?

Hi Souvik,

Some minor comments inline.

Thanks,
Mark

>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Dey, Souvik
>Sent: Saturday, October 1, 2016 10:09 AM
>To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; 
>stephen at networkplumber.org; dev at dpdk.org
>Subject: RE: [PATCH v7] net/virtio: add set_mtu in virtio
>
>Hi Liu/Stephen/Mark,
>
>   I have submitted Version 7 of this patch. Do let me know if this looks 
> proper.
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Dey, Souvik
>Sent: Thursday, September 29, 2016 4:32 PM
>To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; 
>stephen at networkplumber.org; dev at dpdk.org
>Cc: Dey, Souvik 
>Subject: [PATCH v7] net/virtio: add set_mtu in virtio
>
>
>Virtio interfaces do not currently allow the user to specify a 
>particular Maximum Transmission Unit (MTU).Consequently, the MTU of 
>Virtio interfaces is typically set to the Ethernet default value of 1500.
>This is problematic in the case of cloud deployments, in which a 
>specific (and potentially non-standard) MTU needs to be set by a DHCP 
>server, which needs to be honored by all interfaces across the traffic 
>path.To achieve this Virtio interfaces should support setting of MTU.
>In case when GRE/VXLAN tunneling is used for internal communication, 
>there will be an overhead added by the infrastructure in the packet 
>over and above the ETHER MTU of 1518. So to take care of this overhead 
>in these cases the DHCP server corrects the L3 MTU to 1454. But since 
>virtio interfaces was not having the MTU set functionality that MTU 
>sent by the DHCP server was ignored and the instance will still send 
>packets with 1500 MTU which after encapsulation will become more than
>1518 and eventually gets dropped in the infrastructure.
>By adding an additional 'set_mtu' function to the Virtio driver, we can 
>honor the MTU sent by the DHCP server. The dhcp server/controller can 
>then leverage this 'set_mtu' functionality to resolve the above 
>mentioned issue of packets getting dropped due to incorrect size.
>
>
>Signed-off-by: Souvik Dey 
>
>---
>Changes in v7:
>- Replaced the CRC_LEN with the merge rx buf header length.
>- Changed the frame_len max validation to VIRTIO_MAX_RX_PKTLEN.
>Changes in v6:
>- Description of change corrected
>- Corrected the identations
>- Corrected the subject line too
>- The From line was also not correct
>- Re-submitting as the below patch was not proper Changes in v5:
>- Fix log message for out-of-bounds MTU parameter in virtio_mtu_set
>- Calculate frame size, based on 

[dpdk-dev] [PATCH v7] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Yes Mark, I have modified the patch with the below comments.

drivers/net/virtio/virtio_ethdev.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 423c597..1dbfea6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
 } 

+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */
+
+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
+   hw->vtnet_hdr_size;
+   uint32_t frame_size = mtu + ether_hdr_len;
+
+   if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
+   ETHER_MIN_MTU, (VIRTIO_MAX_RX_PKTLEN - ether_hdr_len));
+   return -EINVAL;
+   }
+   return 0;
+}

Let mem know if this looks good or we have few more comments. 

--
Regards,
Souvik

-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com] 
Sent: Wednesday, October 5, 2016 4:16 AM
To: Dey, Souvik ; yuanhan.liu at linux.intel.com; 
stephen at networkplumber.org
Cc: dev at dpdk.org
Subject: RE: [PATCH v7] net/virtio: add set_mtu in virtio

>Hi All,
>   Is there any further comments or modifications required for this 
>patch, or what next steps do you guys suggest here ?

Hi Souvik,

Some minor comments inline.

Thanks,
Mark

>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Dey, Souvik
>Sent: Saturday, October 1, 2016 10:09 AM
>To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; 
>stephen at networkplumber.org; dev at dpdk.org
>Subject: RE: [PATCH v7] net/virtio: add set_mtu in virtio
>
>Hi Liu/Stephen/Mark,
>
>   I have submitted Version 7 of this patch. Do let me know if this looks 
> proper.
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Dey, Souvik
>Sent: Thursday, September 29, 2016 4:32 PM
>To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; 
>stephen at networkplumber.org; dev at dpdk.org
>Cc: Dey, Souvik 
>Subject: [PATCH v7] net/virtio: add set_mtu in virtio
>
>
>Virtio interfaces do not currently allow the user to specify a 
>particular Maximum Transmission Unit (MTU).Consequently, the MTU of 
>Virtio interfaces is typically set to the Ethernet default value of 1500.
>This is problematic in the case of cloud deployments, in which a 
>specific (and potentially non-standard) MTU needs to be set by a DHCP 
>server, which needs to be honored by all interfaces across the traffic 
>path.To achieve this Virtio interfaces should support setting of MTU.
>In case when GRE/VXLAN tunneling is used for internal communication, 
>there will be an overhead added by the infrastructure in the packet 
>over and above the ETHER MTU of 1518. So to take care of this overhead 
>in these cases the DHCP server corrects the L3 MTU to 1454. But since 
>virtio interfaces was not having the MTU set functionality that MTU 
>sent by the DHCP server was ignored and the instance will still send 
>packets with 1500 MTU which after encapsulation will become more than 
>1518 and eventually gets dropped in the infrastructure.
>By adding an additional 'set_mtu' function to the Virtio driver, we can 
>honor the MTU sent by the DHCP server. The dhcp server/controller can 
>then leverage this 'set_mtu' functionality to resolve the above 
>mentioned issue of packets getting dropped due to incorrect size.
>
>
>Signed-off-by: Souvik Dey 
>
>---
>Changes in v7:
>- Replaced the CRC_LEN with the merge rx buf header length.
>- Changed the frame_len max validation to VIRTIO_MAX_RX_PKTLEN.
>Changes in v6:
>- Description of change corrected
>- Corrected the identations
>- Corrected the subject line too
>- The From line was also not correct
>- Re-submitting as the below patch was not proper Changes in v5:
>- Fix log message for out-of-bounds MTU parameter in virtio_mtu_set
>- Calculate frame size, based on 'mtu' parameter
>- Corrected the upper bound and lower bound checks in virtio_mtu_set 
>Changes in v4: Incorporated review comments.
>Changes in v3: Corrected few style errors as reported by sys-stv.
>Changes in v2: Incorporated review comments.
>
> drivers/net/virtio/virtio_ethdev.c | 16 
> 1 file changed, 16 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c

[dpdk-dev] [PATCH v7] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi All,
Is there any further comments or modifications required for this patch, 
or what next steps do you guys suggest here ?

--
Regards,
Souvik

-Original Message-
From: Dey, Souvik 
Sent: Saturday, October 1, 2016 10:09 AM
To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; stephen at 
networkplumber.org; dev at dpdk.org
Subject: RE: [PATCH v7] net/virtio: add set_mtu in virtio

Hi Liu/Stephen/Mark,

I have submitted Version 7 of this patch. Do let me know if this looks 
proper.

--
Regards,
Souvik  

-Original Message-
From: Dey, Souvik 
Sent: Thursday, September 29, 2016 4:32 PM
To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; stephen at 
networkplumber.org; dev at dpdk.org
Cc: Dey, Souvik 
Subject: [PATCH v7] net/virtio: add set_mtu in virtio


Virtio interfaces do not currently allow the user to specify a particular 
Maximum Transmission Unit (MTU).Consequently, the MTU of Virtio interfaces 
is typically set to the Ethernet default value of 1500.
This is problematic in the case of cloud deployments, in which a specific
(and potentially non-standard) MTU needs to be set by a DHCP server, which 
needs to be honored by all interfaces across the traffic path.To acheive 
this Virtio interfaces should support setting of MTU.
In case when GRE/VXLAN tunneling is used for internal communication, there 
will be an overhead added by the infrastructure in the packet over and 
above the ETHER MTU of 1518. So to take care of this overhead in these 
cases the DHCP server corrects the L3 MTU to 1454. But since virtio 
interfaces was not having the MTU set functionality that MTU sent by the 
DHCP server was ignored and the instance will still send packets with 1500 
MTU which after encapsulation will become more than 1518 and eventually 
gets dropped in the infrastructure. 
By adding an additional 'set_mtu' function to the Virtio driver, we can 
honor the MTU sent by the DHCP server. The dhcp server/controller can 
then leverage this 'set_mtu' functionality to resolve the above 
mentioned issue of packets getting dropped due to incorrect size.


Signed-off-by: Souvik Dey 

---
Changes in v7:
- Replaced the CRC_LEN with the merge rx buf header length.
- Changed the frame_len max validation to VIRTIO_MAX_RX_PKTLEN.
Changes in v6:
- Description of change corrected
- Corrected the identations
- Corrected the subject line too
- The From line was also not correct
- Re-submitting as the below patch was not proper
Changes in v5: 
- Fix log message for out-of-bounds MTU parameter in virtio_mtu_set
- Calculate frame size, based on 'mtu' parameter
- Corrected the upper bound and lower bound checks in virtio_mtu_set
Changes in v4: Incorporated review comments.
Changes in v3: Corrected few style errors as reported by sys-stv.
Changes in v2: Incorporated review comments.

 drivers/net/virtio/virtio_ethdev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 423c597..1dbfea6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
 } 

+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */
+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
+   hw->vtnet_hdr_size;
+   uint32_t frame_size = mtu + ether_hdr_len;
+
+   if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
+   ETHER_MIN_MTU, VIRTIO_MAX_RX_PKTLEN);
+   return -EINVAL;
+   }
+   return 0;
+}

 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,
.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
.xstats_get  = virtio_dev_xstats_get,
-- 
2.9.3.windows.1

[dpdk-dev] [PATCH v7] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi Liu/Stephen/Mark,

I have submitted Version 7 of this patch. Do let me know if this looks 
proper.

--
Regards,
Souvik  

-Original Message-
From: Dey, Souvik 
Sent: Thursday, September 29, 2016 4:32 PM
To: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; stephen at 
networkplumber.org; dev at dpdk.org
Cc: Dey, Souvik 
Subject: [PATCH v7] net/virtio: add set_mtu in virtio


Virtio interfaces do not currently allow the user to specify a particular 
Maximum Transmission Unit (MTU).Consequently, the MTU of Virtio interfaces 
is typically set to the Ethernet default value of 1500.
This is problematic in the case of cloud deployments, in which a specific
(and potentially non-standard) MTU needs to be set by a DHCP server, which 
needs to be honored by all interfaces across the traffic path.To acheive 
this Virtio interfaces should support setting of MTU.
In case when GRE/VXLAN tunneling is used for internal communication, there 
will be an overhead added by the infrastructure in the packet over and 
above the ETHER MTU of 1518. So to take care of this overhead in these 
cases the DHCP server corrects the L3 MTU to 1454. But since virtio 
interfaces was not having the MTU set functionality that MTU sent by the 
DHCP server was ignored and the instance will still send packets with 1500 
MTU which after encapsulation will become more than 1518 and eventually 
gets dropped in the infrastructure. 
By adding an additional 'set_mtu' function to the Virtio driver, we can 
honor the MTU sent by the DHCP server. The dhcp server/controller can 
then leverage this 'set_mtu' functionality to resolve the above 
mentioned issue of packets getting dropped due to incorrect size.


Signed-off-by: Souvik Dey 

---
Changes in v7:
- Replaced the CRC_LEN with the merge rx buf header length.
- Changed the frame_len max validation to VIRTIO_MAX_RX_PKTLEN.
Changes in v6:
- Description of change corrected
- Corrected the identations
- Corrected the subject line too
- The From line was also not correct
- Re-submitting as the below patch was not proper
Changes in v5: 
- Fix log message for out-of-bounds MTU parameter in virtio_mtu_set
- Calculate frame size, based on 'mtu' parameter
- Corrected the upper bound and lower bound checks in virtio_mtu_set
Changes in v4: Incorporated review comments.
Changes in v3: Corrected few style errors as reported by sys-stv.
Changes in v2: Incorporated review comments.

 drivers/net/virtio/virtio_ethdev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 423c597..1dbfea6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
 } 

+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */
+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
+   hw->vtnet_hdr_size;
+   uint32_t frame_size = mtu + ether_hdr_len;
+
+   if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
+   ETHER_MIN_MTU, VIRTIO_MAX_RX_PKTLEN);
+   return -EINVAL;
+   }
+   return 0;
+}

 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,
.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
.xstats_get  = virtio_dev_xstats_get,
-- 
2.9.3.windows.1

[dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio

[Dey, Souvik]

OK sure will do that. 

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Tuesday, September 27, 2016 7:12 PM
To: Dey, Souvik 
Cc: Stephen Hemminger ; Kavanagh, Mark B 
; dev at dpdk.org
Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

On Tue, Sep 27, 2016 at 08:44:20PM +, Dey, Souvik wrote:
> Hi Stephen, 
>   So what should be my next steps , should I submit a v7 for this patch 
> or you suggest otherwise.

Yes, please. Another note is please don't use white space for indentation, use 
TAB instead.

-yliu
> 
> --
> Regards,
> Souvik
> 
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, September 27, 2016 2:57 PM
> To: Dey, Souvik 
> Cc: Kavanagh, Mark B ; Yuanhan Liu 
> ; dev at dpdk.org
> Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> On Fri, 23 Sep 2016 15:17:37 +
> "Dey, Souvik"  wrote:
> 
> > Hi Liu/Mark/Stephen,
> > 
> >   I have tried to modify the code with all of your latest 
> > comments. Do let me know if this looks fine or you have more comments.
> > 
> > 
> > 
> > Changes done :
> > 
> > -- max frame ize is compare to VIRTIO_MAX_RX_PKTLEN instead of 
> > dev_info.max_rx_pktlen
> > 
> > -- removed the CRC_LEN from the ether_len calculation and added the 
> > merge rx buf hdr len. ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE 
> > +
> > hw->vtnet_hdr_size
> > 
> > -- Still retained the VLAN Size as the worst case scenario.
> > 
> > 
> > 
> > 
> > 
> > --
> > 
> > drivers/net/virtio/virtio_ethdev.c | 16 
> > 
> > 1 file changed, 16 insertions(+)
> > 
> > 
> > 
> > diff --git a/drivers/net/virtio/virtio_ethdev.c
> > b/drivers/net/virtio/virtio_ethdev.c
> > 
> > index 423c597..1dbfea6 100644
> > 
> > --- a/drivers/net/virtio/virtio_ethdev.c
> > 
> > +++ b/drivers/net/virtio/virtio_ethdev.c
> > 
> > @@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct
> > rte_eth_dev *dev)
> > 
> > PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
> > 
> > }
> > 
> > 
> > 
> > +#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */
> > 
> > +
> > 
> > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> > 
> > +{
> > 
> > +struct virtio_hw *hw = dev->data->dev_private;
> > 
> > +uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE 
> > + +
> > + hw->vtnet_hdr_size;
> > 
> > +uint32_t frame_size = mtu + ether_hdr_len;
> > 
> > +
> > 
> > +if (mtu < ETHER_MIN_MTU || frame_size > 
> > + VIRTIO_MAX_RX_PKTLEN ) {
> > 
> > +   PMD_INIT_LOG(ERR, "MTU should be between 
> > + %d and %d\n",
> > 
> > + ETHER_MIN_MTU, 
> > + VIRTIO_MAX_RX_PKTLEN);
> > 
> > +   return -EINVAL;
> > 
> > +}
> > 
> > +return 0;
> > 
> > +}
> > 
> > 
> > 
> > /*
> > 
> >   * dev_ops for virtio, bare necessities for basic operation
> > 
> >   */
> > 
> > @@ -677,7 +685,6 @@ static const struct eth_dev_ops 
> > virtio_eth_dev_ops = {
> > 
> >  .allmulticast_enable = virtio_dev_allmulticast_enable,
> > 
> >      .allmulticast_disable= virtio_dev_allmulticast_disable,
> > 
> > +.mtu_set = virtio_mtu_set,
> > 
> >  .dev_infos_get   = virtio_dev_info_get,
> > 
> >  .stats_get   = virtio_dev_stats_get,
> > 
> >  .xstats_get  = virtio_dev_xstats_get,
> > 
> > --
> > 
> > Please do let me know if this looks good to you all. Thanks
> > 
> > 
> > 
> > --
> > 
> > Regards,
> > 
> > Souvik
> > 
> > 
> > 
> > -Original Message-
> > From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
> > Sent: Friday, September 23, 2016 5:08 AM
> > To: Yuanhan Liu ; Stephen Hemminger 
> > 
> > Cc: Dey, Souvik ; dev at dpdk.org
> > Subject: RE: [PATCH v6] net/virtio: add set_mtu in virtio
> > 
> > 
> > 
> > >Subject: Re: [PATCH v6] net/virti

[dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi Stephen, 
So what should be my next steps , should I submit a v7 for this patch 
or you suggest otherwise.

--
Regards,
Souvik

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Tuesday, September 27, 2016 2:57 PM
To: Dey, Souvik 
Cc: Kavanagh, Mark B ; Yuanhan Liu ; dev at dpdk.org
Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

On Fri, 23 Sep 2016 15:17:37 +
"Dey, Souvik"  wrote:

> Hi Liu/Mark/Stephen,
> 
>   I have tried to modify the code with all of your latest 
> comments. Do let me know if this looks fine or you have more comments.
> 
> 
> 
> Changes done :
> 
> -- max frame ize is compare to VIRTIO_MAX_RX_PKTLEN instead of 
> dev_info.max_rx_pktlen
> 
> -- removed the CRC_LEN from the ether_len calculation and added the 
> merge rx buf hdr len. ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE + 
> hw->vtnet_hdr_size
> 
> -- Still retained the VLAN Size as the worst case scenario.
> 
> 
> 
> 
> 
> --
> 
> drivers/net/virtio/virtio_ethdev.c | 16 
> 
> 1 file changed, 16 insertions(+)
> 
> 
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> 
> index 423c597..1dbfea6 100644
> 
> --- a/drivers/net/virtio/virtio_ethdev.c
> 
> +++ b/drivers/net/virtio/virtio_ethdev.c
> 
> @@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct 
> rte_eth_dev *dev)
> 
> PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
> 
> }
> 
> 
> 
> +#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */
> 
> +
> 
> +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> 
> +{
> 
> +struct virtio_hw *hw = dev->data->dev_private;
> 
> +uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE + 
> + hw->vtnet_hdr_size;
> 
> +uint32_t frame_size = mtu + ether_hdr_len;
> 
> +
> 
> +if (mtu < ETHER_MIN_MTU || frame_size > 
> + VIRTIO_MAX_RX_PKTLEN ) {
> 
> +   PMD_INIT_LOG(ERR, "MTU should be between 
> + %d and %d\n",
> 
> + ETHER_MIN_MTU, 
> + VIRTIO_MAX_RX_PKTLEN);
> 
> +   return -EINVAL;
> 
> +}
> 
> +return 0;
> 
> +}
> 
> 
> 
> /*
> 
>   * dev_ops for virtio, bare necessities for basic operation
> 
>   */
> 
> @@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops 
> = {
> 
>  .allmulticast_enable = virtio_dev_allmulticast_enable,
> 
>  .allmulticast_disable= virtio_dev_allmulticast_disable,
> 
> +.mtu_set = virtio_mtu_set,
> 
>  .dev_infos_get   = virtio_dev_info_get,
> 
>  .stats_get   = virtio_dev_stats_get,
> 
>      .xstats_get  = virtio_dev_xstats_get,
> 
> --
> 
> Please do let me know if this looks good to you all. Thanks
> 
> 
> 
> --
> 
> Regards,
> 
> Souvik
> 
> 
> 
> -Original Message-
> From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
> Sent: Friday, September 23, 2016 5:08 AM
> To: Yuanhan Liu ; Stephen Hemminger 
> 
> Cc: Dey, Souvik ; dev at dpdk.org
> Subject: RE: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> 
> 
> >Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> >
> 
> >On Wed, Sep 21, 2016 at 06:45:05PM -0700, Stephen Hemminger wrote:
> 
> >> On Thu, 22 Sep 2016 00:08:38 +
> 
> >> "Dey, Souvik" mailto:sodey at sonusnet.com>> wrote:
> 
> >>
> 
> >> > Answers inline.
> 
> >> >
> 
> >> > --
> 
> >> > Regards,
> 
> >> > Souvik
> 
> >> >
> 
> >> > -Original Message-
> 
> >> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> 
> >> > Sent: Wednesday, September 21, 2016 7:22 PM
> 
> >> > To: Dey, Souvik mailto:sodey at sonusnet.com>>
> 
> >> > Cc: mark.b.kavanagh at intel.com<mailto:mark.b.kavanagh at intel.com>; 
> >> > yuanhan.liu at linux.intel.com<mailto:yuanhan.liu at linux.intel.com>;
> 
> >> > dev at dpdk.org<mailto:dev at dpdk.org>
> 
> >> > Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> >> >
> 
> >> > On Wed, 21 Sep 2016 19:11:47 -0400
> 
> >> > Dey mailto:sodey at sonusne

[dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi All,
Any further updates/comments on this ?

--
Regards,
Souvik

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Sunday, September 25, 2016 11:21 PM
To: Stephen Hemminger 
Cc: Dey, Souvik ; Kavanagh, Mark B ; dev at dpdk.org
Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

Hi Stephen,

Are you okay with this change?

--yliu

On Fri, Sep 23, 2016 at 03:17:37PM +, Dey, Souvik wrote:
> Hi Liu/Mark/Stephen,
> 
>   I have tried to modify the code with all of your latest 
> comments.
> Do let me know if this looks fine or you have more comments.
> 
>  
> 
> Changes done :
> 
> -- max frame ize is compare to VIRTIO_MAX_RX_PKTLEN instead of 
> dev_info.max_rx_pktlen
> 
> -- removed the CRC_LEN from the ether_len calculation and added the 
> merge rx buf hdr len. ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE + 
> hw->vtnet_hdr_size
> 
> -- Still retained the VLAN Size as the worst case scenario.
> 
>  
> 
>  
> 
> --
> 
> drivers/net/virtio/virtio_ethdev.c | 16 
> 
> 1 file changed, 16 insertions(+)
> 
>  
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/ 
> virtio_ethdev.c
> 
> index 423c597..1dbfea6 100644
> 
> --- a/drivers/net/virtio/virtio_ethdev.c
> 
> +++ b/drivers/net/virtio/virtio_ethdev.c
> 
> @@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct 
> rte_eth_dev *dev)
> 
> PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
> 
> }
> 
>  
> 
> +#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */
> 
> +
> 
> +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
> 
> +{
> 
> +struct virtio_hw *hw = dev->data->dev_private;
> 
> +uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE + 
> + hw->
> vtnet_hdr_size;
> 
> +uint32_t frame_size = mtu + ether_hdr_len;
> 
> +
> 
> +if (mtu < ETHER_MIN_MTU || frame_size > 
> + VIRTIO_MAX_RX_PKTLEN ) {
> 
> +   PMD_INIT_LOG(ERR, "MTU should be between 
> + %d and %d\
> n",
> 
> + ETHER_MIN_MTU, 
> + VIRTIO_MAX_RX_PKTLEN);
> 
> +   return -EINVAL;
> 
> +}
> 
> +return 0;
> 
> +}
> 
>  
> 
> /*
> 
>   * dev_ops for virtio, bare necessities for basic operation
> 
>   */
> 
> @@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops 
> = {
> 
>  .allmulticast_enable = virtio_dev_allmulticast_enable,
> 
>  .allmulticast_disable= virtio_dev_allmulticast_disable,
> 
> +.mtu_set = virtio_mtu_set,
> 
>  .dev_infos_get   = virtio_dev_info_get,
> 
>  .stats_get   = virtio_dev_stats_get,
> 
>          .xstats_get  = virtio_dev_xstats_get,
> 
> --
> 
> Please do let me know if this looks good to you all. Thanks
> 
>  
> 
> --
> 
> Regards,
> 
> Souvik
> 
>  
> 
> -Original Message-
> From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
> Sent: Friday, September 23, 2016 5:08 AM
> To: Yuanhan Liu ; Stephen Hemminger 
> 
> Cc: Dey, Souvik ; dev at dpdk.org
> Subject: RE: [PATCH v6] net/virtio: add set_mtu in virtio
> 
>  
> 
> >Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> > 
> 
> >On Wed, Sep 21, 2016 at 06:45:05PM -0700, Stephen Hemminger wrote:
> 
> >> On Thu, 22 Sep 2016 00:08:38 +
> 
> >> "Dey, Souvik"  wrote:
> 
> >> 
> 
> >> > Answers inline.
> 
> >> >
> 
> >> > --
> 
> >> > Regards,
> 
> >> > Souvik
> 
> >> >
> 
> >> > -Original Message-
> 
> >> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> 
> >> > Sent: Wednesday, September 21, 2016 7:22 PM
> 
> >> > To: Dey, Souvik 
> 
> >> > Cc: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com;
> 
> >> > dev at dpdk.org
> 
> >> > Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> >> >
> 
> >> > On Wed, 21 Sep 2016 19:11:47 -0400
> 
> >> > Dey  wrote:
> 
> >> >
> 
> >> > >
> 
> >> > > +
> 
> >> > > +#define VLAN_TAG_SIZE   4/* 802.3ac

[dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Hi Liu/Mark/Stephen,

  I have tried to modify the code with all of your latest comments. 
Do let me know if this looks fine or you have more comments.



Changes done :

-- max frame ize is compare to VIRTIO_MAX_RX_PKTLEN instead of 
dev_info.max_rx_pktlen

-- removed the CRC_LEN from the ether_len calculation and added the merge rx 
buf hdr len. ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE + hw->vtnet_hdr_size

-- Still retained the VLAN Size as the worst case scenario.





--

drivers/net/virtio/virtio_ethdev.c | 16 

1 file changed, 16 insertions(+)



diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c

index 423c597..1dbfea6 100644

--- a/drivers/net/virtio/virtio_ethdev.c

+++ b/drivers/net/virtio/virtio_ethdev.c

@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

PMD_INIT_LOG(ERR, "Failed to disable allmulticast");

}



+#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */

+

+static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

+{

+struct virtio_hw *hw = dev->data->dev_private;

+uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_SIZE + 
hw->vtnet_hdr_size;

+uint32_t frame_size = mtu + ether_hdr_len;

+

+if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN ) {

+   PMD_INIT_LOG(ERR, "MTU should be between %d and 
%d\n",

+ ETHER_MIN_MTU, VIRTIO_MAX_RX_PKTLEN);

+   return -EINVAL;

+}

+return 0;

+}



/*

  * dev_ops for virtio, bare necessities for basic operation

  */

@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {

 .allmulticast_enable = virtio_dev_allmulticast_enable,

 .allmulticast_disable= virtio_dev_allmulticast_disable,

+.mtu_set = virtio_mtu_set,

 .dev_infos_get   = virtio_dev_info_get,

 .stats_get   = virtio_dev_stats_get,

 .xstats_get  = virtio_dev_xstats_get,

--

Please do let me know if this looks good to you all. Thanks



--

Regards,

Souvik



-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Friday, September 23, 2016 5:08 AM
To: Yuanhan Liu ; Stephen Hemminger 
Cc: Dey, Souvik ; dev at dpdk.org
Subject: RE: [PATCH v6] net/virtio: add set_mtu in virtio



>Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

>

>On Wed, Sep 21, 2016 at 06:45:05PM -0700, Stephen Hemminger wrote:

>> On Thu, 22 Sep 2016 00:08:38 +

>> "Dey, Souvik" mailto:sodey at sonusnet.com>> wrote:

>>

>> > Answers inline.

>> >

>> > --

>> > Regards,

>> > Souvik

>> >

>> > -Original Message-

>> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]

>> > Sent: Wednesday, September 21, 2016 7:22 PM

>> > To: Dey, Souvik mailto:sodey at sonusnet.com>>

>> > Cc: mark.b.kavanagh at intel.com<mailto:mark.b.kavanagh at intel.com>; 
>> > yuanhan.liu at linux.intel.com<mailto:yuanhan.liu at linux.intel.com>;

>> > dev at dpdk.org<mailto:dev at dpdk.org>

>> > Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

>> >

>> > On Wed, 21 Sep 2016 19:11:47 -0400

>> > Dey mailto:sodey at sonusnet.com>> wrote:

>> >

>> > >

>> > > +

>> > > +#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */

>> > > +

>> > > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {

>> > > +   struct rte_eth_dev_info dev_info;

>> > > +   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
>> > > VLAN_TAG_SIZE;

>> > > +   uint32_t frame_size = mtu + ether_hdr_len;

>> > > +

>> > > +   virtio_dev_info_get(dev, &dev_info);

>> > > +

>> > > +   if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) {

>> > > +   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",

>> > > +   ETHER_MIN_MTU,

>> > > +   (dev_info.max_rx_pktlen - 
>> > > ether_hdr_len));

>> > > +   return -EINVAL;

>> > > +   }

>> > > +   return 0;

>> > > +}

>> >

>> > I am fine with the general idea of this patch but:

>> >   1. Calling virtio_dev_info_get is needlessly wasteful when all you want

>>

[dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio

[Dey, Souvik]

I still fail to understand how the dev_info.max_rx_pktlen is wrong here, and 
the hw->rx_max_pktlen is defined at all ? If you see the other driver code we 
have used the same way there too. Also for the vlan part isn't it better the 
take the worst case for the mtu lower boundary check, as that will be valid for 
both vlan offload on and off cases. 

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Wednesday, September 21, 2016 9:45 PM
To: Dey, Souvik 
Cc: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; dev at 
dpdk.org
Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

On Thu, 22 Sep 2016 00:08:38 +0000
"Dey, Souvik"  wrote:

> Answers inline.
> 
> --
> Regards,
> Souvik
> 
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, September 21, 2016 7:22 PM
> To: Dey, Souvik 
> Cc: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; 
> dev at dpdk.org
> Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio
> 
> On Wed, 21 Sep 2016 19:11:47 -0400
> Dey  wrote:
> 
> >  
> > +
> > +#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */
> > +
> > +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> > +   struct rte_eth_dev_info dev_info;
> > +   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
> > VLAN_TAG_SIZE;
> > +   uint32_t frame_size = mtu + ether_hdr_len;
> > +
> > +   virtio_dev_info_get(dev, &dev_info);
> > +
> > +   if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) {
> > +   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
> > +   ETHER_MIN_MTU,
> > +   (dev_info.max_rx_pktlen - ether_hdr_len));
> > +   return -EINVAL;
> > +   }
> > +   return 0;
> > +}
> 
> I am fine with the general idea of this patch but:
>   1. Calling virtio_dev_info_get is needlessly wasteful when all you want
>  is to access the max packet length. Since max_rx_pktlen is always
>  VIRTIO_MAX_RX_PKTLEN, please just use that.
> [Dey, Souvik] I am using the virtio_dev_info_get as in future can/may support 
> the max_rx_pktlen as a variable to be set by  the application. This will keep 
> the changes future proof. As we need to support till 65535 instead of 9728 as 
> the linux does.

Fine, then just dereference hw->rx_max_pktlen. Driver code can/should reference 
its own data directly.

> 
>   2. Defining VLAN_TAG_SIZE is irrelevant if doing vlan offload.
> [Dey, Souvik] vlan offload is not mandatory. Se again still have vlan being 
> sent up to the application. In that case we need to consider the vlan length 
> in the Ethernet size.

The code needs to handle both vlan offload (or not), correctly. You are 
assuming the worst case here.

> 
>   3. Virtio doesn't insert CRC, therefore CRC_LEN is irrelevant [Dey, 
> Souvik] I am not sure of this. Mark commented earlier to consider this length 
> too. Mark what do you suggest ?

Actually, the thing that matters is the size of the merge rx buf header, not 
the CRC.

The patch is still buggy.

[dpdk-dev] Issue with patchwork

[Dey, Souvik]

Hi All,
  I am sending git send-mail and the patch mail is also getting 
sent but I am not able see the patch in the patchwork link. Can someone point 
what  might have gone wrong. It was working fine earlier though.
Thanks in advance for any kind of help.
--
Regards,
Souvik

[dpdk-dev] [PATCH v6] net/virtio: add set_mtu in virtio

[Dey, Souvik]

Answers inline.

--
Regards,
Souvik

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Wednesday, September 21, 2016 7:22 PM
To: Dey, Souvik 
Cc: mark.b.kavanagh at intel.com; yuanhan.liu at linux.intel.com; dev at 
dpdk.org
Subject: Re: [PATCH v6] net/virtio: add set_mtu in virtio

On Wed, 21 Sep 2016 19:11:47 -0400
Dey  wrote:

>  
> +
> +#define VLAN_TAG_SIZE   4/* 802.3ac tag (not DMA'd) */
> +
> +static int virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> +   struct rte_eth_dev_info dev_info;
> +   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
> VLAN_TAG_SIZE;
> +   uint32_t frame_size = mtu + ether_hdr_len;
> +
> +   virtio_dev_info_get(dev, &dev_info);
> +
> +   if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) {
> +   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
> +   ETHER_MIN_MTU,
> +   (dev_info.max_rx_pktlen - ether_hdr_len));
> +   return -EINVAL;
> +   }
> +   return 0;
> +}

I am fine with the general idea of this patch but:
  1. Calling virtio_dev_info_get is needlessly wasteful when all you want
 is to access the max packet length. Since max_rx_pktlen is always
 VIRTIO_MAX_RX_PKTLEN, please just use that.
[Dey, Souvik] I am using the virtio_dev_info_get as in future can/may support 
the max_rx_pktlen as a variable to be set by  the application. This will keep 
the changes future proof. As we need to support till 65535 instead of 9728 as 
the linux does.

  2. Defining VLAN_TAG_SIZE is irrelevant if doing vlan offload.
[Dey, Souvik] vlan offload is not mandatory. Se again still have vlan being 
sent up to the application. In that case we need to consider the vlan length in 
the Ethernet size.

  3. Virtio doesn't insert CRC, therefore CRC_LEN is irrelevant
[Dey, Souvik] I am not sure of this. Mark commented earlier to consider this 
length too. Mark what do you suggest ?

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

I have already taken care of this in v5 of the patch , If possible please 
review the same .

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Tuesday, September 20, 2016 3:12 AM
To: Kavanagh, Mark B 
Cc: Dey, Souvik ; dev at dpdk.org; stephen at 
networkplumber.org
Subject: Re: [PATCH v4]net/virtio: add mtu set in virtio

On Wed, Sep 14, 2016 at 12:15:37PM +, Kavanagh, Mark B wrote:
> >
> >>+{
> >>+?? struct rte_eth_dev_info dev_info;
> >>+?? uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
> >>+VLAN_TAG_LEN;
> >>+?? uint32_t frame_size = mtu + ether_hdr_len;
> >>+
> >>+?? virtio_dev_info_get(dev, &dev_info);
> >>+
> >>+?? if (mtu < dev_info.min_rx_bufsize || frame_size >
> >>+dev_info.max_rx_pktlen) {
> >
> >It's not clear to me whether 'mtu' in this case should be compared 
> >with ETHER_MIN_MTU, as per other DPDK drivers, or alternatively 
> >whether 'frame_size' should be compared with dev_info.min_rx_bufsize.
> >Any thoughts?
> >[Dey, Souvik] I am not sure why virtio min_rx_bufsize is less than 
> >ETHER_MIN_MTU, i think it will be good to have the  compare statement 
> >as If(frame_size < ETHER_MIN_MTU || frame_size > 
> >dev_info.max_rx_pktlen) , then error. What do you suggest ?
> 
> Again, this all depends on what 'mtu' means in this context.
> 
> Since you mentioned previously that it relates to the packet (i.e. L3) 
> length, and not the frame (i.e. L2) length, I would suggest that the 
> comparison should be:
> 
>   if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen)
> 
> Yuanhan, any thoughts on this?

I think you are right. At least, that's how the ixgbe PMD driver code looks 
like.

--yliu

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Mark/Liu,
I know this might be a redundant question, but should I put your names 
in the Reviewed-by section in v5 ? 

--
Regards,
Souvik

-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com] 
Sent: Wednesday, September 14, 2016 8:16 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio

>
>>
>>Hi Mark/Liu,
>>? Thanks to both of you for being so patient with a series 
>>of silly errors. I have tried to make it better this time. Also there 
>>were some un-used variable in the function which I have removed. 
>>Please check the new patch with all your comments incorporated. Also 
>>along with the L2_HDR_LEN and
>L2_CRC_LEN, I have taken in consideration the VLAN_LEN too.
>>
>>One doubt though,
>>"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 
>>size is some constrain due to DPDK as the virtio driver in the kernel 
>>can support till mtu size of 68 to 65535, where as in DPDK pmd we are 
>>trying with 64 to
>9728.
>
>Yes, I meant the NIC as controlled by a DPDK PMD (I thought this was 
>implicit, given the context of this discussion). I'll be more explicit in 
>future mails though.
>
>>
>>drivers/net/virtio/virtio_ethdev.c | 19 +++
>>1 file changed, 19 insertions(+)
>>
>>diff --git a/drivers/net/virtio/virtio_ethdev.c
>>b/drivers/net/virtio/virtio_ethdev.c
>>index 07d6449..da16ad4 100644
>>--- a/drivers/net/virtio/virtio_ethdev.c
>>+++ b/drivers/net/virtio/virtio_ethdev.c
>>@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct
>>rte_eth_dev *dev)
>>??? PMD_INIT_LOG(ERR, "Failed to disable allmulticast"); }
>>
>>+#define VLAN_TAG_LEN?? 4??? /* 802.3ac tag (not DMA'd) */
>>+
>>+static int? virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
>
>One thing on this function: it doesn't actually set any fields, but 
>rather just sanitizes 'mtu'.
>Maybe this is acceptable, since the calling function (i.e. 
>rte_eth_dev_set_mtu) sets rte_eth_dev->data->mtu?
>[Dey, Souvik]  Yes , only the sanity check for the mtu is required here 
>and the setting of the call back, else the rte_eth_dev_set_mtu() just 
>returns without setting the MTU in the rte_eth_dev->data->mtu.

Hi Souvik, apologies for the delayed response.

That's what I thought, just wanted to verify that no additional structures 
should be updated here.

>
>>+{
>>+?? struct rte_eth_dev_info dev_info;
>>+?? uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
>>+VLAN_TAG_LEN;
>>+?? uint32_t frame_size = mtu + ether_hdr_len;
>>+
>>+?? virtio_dev_info_get(dev, &dev_info);
>>+
>>+?? if (mtu < dev_info.min_rx_bufsize || frame_size >
>>+dev_info.max_rx_pktlen) {
>
>It's not clear to me whether 'mtu' in this case should be compared with 
>ETHER_MIN_MTU, as per other DPDK drivers, or alternatively whether 
>'frame_size' should be compared with dev_info.min_rx_bufsize.
>Any thoughts?
>[Dey, Souvik] I am not sure why virtio min_rx_bufsize is less than 
>ETHER_MIN_MTU, i think it will be good to have the  compare statement 
>as If(frame_size < ETHER_MIN_MTU || frame_size > 
>dev_info.max_rx_pktlen) , then error. What do you suggest ?

Again, this all depends on what 'mtu' means in this context.

Since you mentioned previously that it relates to the packet (i.e. L3) length, 
and not the frame (i.e. L2) length, I would suggest that the comparison should 
be:

if (mtu < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen)

Yuanhan, any thoughts on this?

>
>>+?? PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
>>+??? ???dev_info.min_rx_bufsize,
>As above.
>
>>+?? (dev_info.max_rx_pktlen - 
>>+ether_hdr_len));
>>+?? return -EINVAL;
>>+?? }
>>+ ??return 0;
>>+}
>>@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops 
>>= {
>>? ??.allmulticast_enable???? = virtio_dev_allmulticast_enable,
>>??? .allmulticast_disable??? = virtio_dev_allmulticast_disable,
>>+?? .mtu_set = virtio_mtu_set,
>>??? .dev_infos_get?? = virtio_dev_info_get,
>>??? .stats_get?? = virtio_dev_stats_get,
>>??? .xstats_get? = virtio_dev_xstats_get,
>>
>>
>>--
>>Regards,
>>Souvik
>>
>>-Original Message-
>>From

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Mark/Liu,
Is there any further comments to the below patch ? Should I submit it 
as v5 of the patch ? 

--
Regards,
Souvik

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dey, Souvik
Sent: Monday, September 12, 2016 11:12 AM
To: Kavanagh, Mark B ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio



-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Monday, September 12, 2016 10:48 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio

>
>Hi Mark/Liu,
>? Thanks to both of you for being so patient with a series 
>of silly errors. I have tried to make it better this time. Also there 
>were some un-used variable in the function which I have removed. Please 
>check the new patch with all your comments incorporated. Also along with the 
>L2_HDR_LEN and L2_CRC_LEN, I have taken in consideration the VLAN_LEN too.
>
>One doubt though,
>"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 
>size is some constrain due to DPDK as the virtio driver in the kernel 
>can support till mtu size of 68 to 65535, where as in DPDK pmd we are trying 
>with 64 to 9728.

Yes, I meant the NIC as controlled by a DPDK PMD (I thought this was implicit, 
given the context of this discussion). I'll be more explicit in future mails 
though.

>
>drivers/net/virtio/virtio_ethdev.c | 19 +++
>1 file changed, 19 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct
>rte_eth_dev *dev)
>??? PMD_INIT_LOG(ERR, "Failed to disable allmulticast"); }
>
>+#define VLAN_TAG_LEN?? 4??? /* 802.3ac tag (not DMA'd) */
>+
>+static int? virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

One thing on this function: it doesn't actually set any fields, but rather just 
sanitizes 'mtu'.
Maybe this is acceptable, since the calling function (i.e. rte_eth_dev_set_mtu) 
sets rte_eth_dev->data->mtu?
[Dey, Souvik]  Yes , only the sanity check for the mtu is required here and the 
setting of the call back, else the rte_eth_dev_set_mtu() just returns without 
setting the MTU in the rte_eth_dev->data->mtu.

>+{
>+?? struct rte_eth_dev_info dev_info;
>+?? uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
>+VLAN_TAG_LEN;
>+?? uint32_t frame_size = mtu + ether_hdr_len;
>+
>+?? virtio_dev_info_get(dev, &dev_info);
>+
>+?? if (mtu < dev_info.min_rx_bufsize || frame_size >
>+dev_info.max_rx_pktlen) {

It's not clear to me whether 'mtu' in this case should be compared with 
ETHER_MIN_MTU, as per other DPDK drivers, or alternatively whether 'frame_size' 
should be compared with dev_info.min_rx_bufsize.
Any thoughts?
[Dey, Souvik] I am not sure why virtio min_rx_bufsize is less than 
ETHER_MIN_MTU, i think it will be good to have the  compare statement as 
If(frame_size < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) , then 
error. What do you suggest ?

>+?? PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
>+??? ???dev_info.min_rx_bufsize,
As above.

>+?? (dev_info.max_rx_pktlen - 
>+ether_hdr_len));
>+?? return -EINVAL;
>+?? }
>+ ??return 0;
>+}
>@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops 
>= {
>? ??.allmulticast_enable = virtio_dev_allmulticast_enable,
>??? .allmulticast_disable??? = virtio_dev_allmulticast_disable,
>+?? .mtu_set = virtio_mtu_set,
>??? .dev_infos_get?? = virtio_dev_info_get,
>??? .stats_get?? = virtio_dev_stats_get,
>??? .xstats_get? = virtio_dev_xstats_get,
>
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
>Sent: Friday, September 9, 2016 11:44 AM
>To: Dey, Souvik ; Yuanhan Liu 
>
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio
>
>>
>>Hi Mark,
>>
>>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>>Changed it .
>>Thanks.
>>The MTU here is L3 MTU.? Setting this will help in reducing the 
>>fragmented/multi-segmented packets and also in case we want to reduce 
>>the MTU below 

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com] 
Sent: Monday, September 12, 2016 10:48 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio

>
>Hi Mark/Liu,
>? Thanks to both of you for being so patient with a series 
>of silly errors. I have tried to make it better this time. Also there 
>were some un-used variable in the function which I have removed. Please 
>check the new patch with all your comments incorporated. Also along with the 
>L2_HDR_LEN and L2_CRC_LEN, I have taken in consideration the VLAN_LEN too.
>
>One doubt though,
>"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 
>size is some constrain due to DPDK as the virtio driver in the kernel 
>can support till mtu size of 68 to 65535, where as in DPDK pmd we are trying 
>with 64 to 9728.

Yes, I meant the NIC as controlled by a DPDK PMD (I thought this was implicit, 
given the context of this discussion). I'll be more explicit in future mails 
though.

>
>drivers/net/virtio/virtio_ethdev.c | 19 +++
>1 file changed, 19 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct 
>rte_eth_dev *dev)
>??? PMD_INIT_LOG(ERR, "Failed to disable allmulticast"); }
>
>+#define VLAN_TAG_LEN?? 4??? /* 802.3ac tag (not DMA'd) */
>+
>+static int? virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

One thing on this function: it doesn't actually set any fields, but rather just 
sanitizes 'mtu'.
Maybe this is acceptable, since the calling function (i.e. rte_eth_dev_set_mtu) 
sets rte_eth_dev->data->mtu?
[Dey, Souvik]  Yes , only the sanity check for the mtu is required here and the 
setting of the call back, else the rte_eth_dev_set_mtu() just returns without 
setting the MTU in the rte_eth_dev->data->mtu.

>+{
>+?? struct rte_eth_dev_info dev_info;
>+?? uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + 
>+VLAN_TAG_LEN;
>+?? uint32_t frame_size = mtu + ether_hdr_len;
>+
>+?? virtio_dev_info_get(dev, &dev_info);
>+
>+?? if (mtu < dev_info.min_rx_bufsize || frame_size > 
>+dev_info.max_rx_pktlen) {

It's not clear to me whether 'mtu' in this case should be compared with 
ETHER_MIN_MTU, as per other DPDK drivers, or alternatively whether 'frame_size' 
should be compared with dev_info.min_rx_bufsize.
Any thoughts?
[Dey, Souvik] I am not sure why virtio min_rx_bufsize is less than 
ETHER_MIN_MTU, i think it will be good to have the  compare statement as 
If(frame_size < ETHER_MIN_MTU || frame_size > dev_info.max_rx_pktlen) , then 
error. What do you suggest ?

>+?? PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
>+??? ???dev_info.min_rx_bufsize,
As above.

>+?? (dev_info.max_rx_pktlen - 
>+ether_hdr_len));
>+?? return -EINVAL;
>+?? }
>+ ??return 0;
>+}
>@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops 
>= {
>? ??.allmulticast_enable = virtio_dev_allmulticast_enable,
>??? .allmulticast_disable??? = virtio_dev_allmulticast_disable,
>+?? .mtu_set = virtio_mtu_set,
>??? .dev_infos_get?? = virtio_dev_info_get,
>??? .stats_get?? = virtio_dev_stats_get,
>??? .xstats_get? = virtio_dev_xstats_get,
>
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Kavanagh, Mark B [mailto:mark.b.kavanagh at intel.com]
>Sent: Friday, September 9, 2016 11:44 AM
>To: Dey, Souvik ; Yuanhan Liu 
>
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio
>
>>
>>Hi Mark,
>>
>>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>>Changed it .
>>Thanks.
>>The MTU here is L3 MTU.? Setting this will help in reducing the 
>>fragmented/multi-segmented packets and also in case we want to reduce 
>>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>>openstack and cloud
>environments.
>>
>>---
>> drivers/net/virtio/virtio_ethdev.c | 12 
>> 1 file changed, 12 insertions(+)
>>
>>diff --git a/drivers/net/virtio/virtio_ethdev.c
>>b/drivers/net/virtio/virtio_ethdev.c
>>index 07d6449..da16ad4 100644
>>--- a/drivers/net/virtio/virtio_ethdev

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi All,
Any further comments or updates to be  made in the below patch else I 
will go ahead a submit the v5 for the same.

--
Regards,
Souvik

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dey, Souvik
Sent: Friday, September 9, 2016 2:16 PM
To: Kavanagh, Mark B ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

Hi Mark/Liu,

  Thanks to both of you for being so patient with a series of silly 
errors. I have tried to make it better this time. Also there were some un-used 
variable in the function which I have removed. Please check the new patch with 
all your comments incorporated. Also along with the L2_HDR_LEN and L2_CRC_LEN, 
I have taken in consideration the VLAN_LEN too.



One doubt though,

"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 size is 
some constrain due to DPDK as the virtio driver in the kernel can support till 
mtu size of 68 to 65535, where as in DPDK pmd we are trying with 64 to 9728.



drivers/net/virtio/virtio_ethdev.c | 19 +++

1 file changed, 19 insertions(+)



diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c

index 07d6449..da16ad4 100644

--- a/drivers/net/virtio/virtio_ethdev.c

+++ b/drivers/net/virtio/virtio_ethdev.c

@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

PMD_INIT_LOG(ERR, "Failed to disable allmulticast");

}



+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */

+

+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

+{

+   struct rte_eth_dev_info dev_info;

+   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_LEN;

+   uint32_t frame_size = mtu + ether_hdr_len;

+

+   virtio_dev_info_get(dev, &dev_info);

+

+   if (mtu < dev_info.min_rx_bufsize || frame_size > 
dev_info.max_rx_pktlen) {

+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",

+   dev_info.min_rx_bufsize,

+   (dev_info.max_rx_pktlen - ether_hdr_len));

+   return -EINVAL;

+   }

+   return 0;

+}

@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {

.allmulticast_enable = virtio_dev_allmulticast_enable,

.allmulticast_disable= virtio_dev_allmulticast_disable,

+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,

.stats_get   = virtio_dev_stats_get,

.xstats_get  = virtio_dev_xstats_get,





--

Regards,

Souvik



-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Friday, September 9, 2016 11:44 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio



>

>Hi Mark,

>

>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>Changed it .

>Thanks.

>The MTU here is L3 MTU.  Setting this will help in reducing the

>fragmented/multi-segmented packets and also in case we want to reduce

>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>openstack and cloud environments.

>

>---

> drivers/net/virtio/virtio_ethdev.c | 12 

> 1 file changed, 12 insertions(+)

>

>diff --git a/drivers/net/virtio/virtio_ethdev.c

>b/drivers/net/virtio/virtio_ethdev.c

>index 07d6449..da16ad4 100644

>--- a/drivers/net/virtio/virtio_ethdev.c

>+++ b/drivers/net/virtio/virtio_ethdev.c

>

>static int virtio_dev_queue_stats_mapping_set(

>__rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@

>virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

>   PMD_INIT_LOG(ERR, "Failed to disable 
> allmulticast");  }

>

>+static int

>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {

>+  struct virtio_hw *hw = dev->data->dev_private;

>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {



If MTU is the L3 MTU as you've indicated, then you need to take account of L2 
overhead before performing the comparison above.

Say the user supplies 'mtu' as 9728 - the corresponding minimum frame size is 
L2_HDR_LEN + 9728 + L2_CRC_LEN = 9746 bytes, which is larger than the NIC can 
accommodate (note that 9728 is the largest L2 frame size allowed by the NIC, 
not the largest IP packet size).



>+PMD_INIT_LOG(ERR, "Mtu should be between 
>VIRTIO_MIN_RX_BUFSIZE and

>VIRTIO_MAX_RX_PKTLEN \n");



Two things on this statement:

1) in the context of a log message, VIRTIO_XXX_RX_BUFSIZE most likely

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Mark/Liu,

  Thanks to both of you for being so patient with a series of silly 
errors. I have tried to make it better this time. Also there were some un-used 
variable in the function which I have removed. Please check the new patch with 
all your comments incorporated. Also along with the L2_HDR_LEN and L2_CRC_LEN, 
I have taken in consideration the VLAN_LEN too.



One doubt though,

"9728 is the largest L2 frame size allowed by the NIC" -- this 9728 size is 
some constrain due to DPDK as the virtio driver in the kernel can support till 
mtu size of 68 to 65535, where as in DPDK pmd we are trying with 64 to 9728.



drivers/net/virtio/virtio_ethdev.c | 19 +++

1 file changed, 19 insertions(+)



diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c

index 07d6449..da16ad4 100644

--- a/drivers/net/virtio/virtio_ethdev.c

+++ b/drivers/net/virtio/virtio_ethdev.c

@@ -653,12 +653,20 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

PMD_INIT_LOG(ERR, "Failed to disable allmulticast");

}



+#define VLAN_TAG_LEN   4/* 802.3ac tag (not DMA'd) */

+

+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)

+{

+   struct rte_eth_dev_info dev_info;

+   uint32_t ether_hdr_len = ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_LEN;

+   uint32_t frame_size = mtu + ether_hdr_len;

+

+   virtio_dev_info_get(dev, &dev_info);

+

+   if (mtu < dev_info.min_rx_bufsize || frame_size > 
dev_info.max_rx_pktlen) {

+   PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",

+   dev_info.min_rx_bufsize,

+   (dev_info.max_rx_pktlen - ether_hdr_len));

+   return -EINVAL;

+   }

+   return 0;

+}

@@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {

.allmulticast_enable = virtio_dev_allmulticast_enable,

.allmulticast_disable= virtio_dev_allmulticast_disable,

+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,

.stats_get   = virtio_dev_stats_get,

.xstats_get  = virtio_dev_xstats_get,





--

Regards,

Souvik



-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com]
Sent: Friday, September 9, 2016 11:44 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio



>

>Hi Mark,

>

>Yes I thought I did that change. Sorry once again.. making too many mistakes. 
>Changed it .

>Thanks.

>The MTU here is L3 MTU.  Setting this will help in reducing the

>fragmented/multi-segmented packets and also in case we want to reduce

>the MTU below 1500, to support VXLAN or GRE tunnel for the packets in 
>openstack and cloud environments.

>

>---

> drivers/net/virtio/virtio_ethdev.c | 12 

> 1 file changed, 12 insertions(+)

>

>diff --git a/drivers/net/virtio/virtio_ethdev.c

>b/drivers/net/virtio/virtio_ethdev.c

>index 07d6449..da16ad4 100644

>--- a/drivers/net/virtio/virtio_ethdev.c

>+++ b/drivers/net/virtio/virtio_ethdev.c

>

>static int virtio_dev_queue_stats_mapping_set(

>__rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@

>virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)

>   PMD_INIT_LOG(ERR, "Failed to disable 
> allmulticast");  }

>

>+static int

>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {

>+  struct virtio_hw *hw = dev->data->dev_private;

>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {



If MTU is the L3 MTU as you've indicated, then you need to take account of L2 
overhead before performing the comparison above.

Say the user supplies 'mtu' as 9728 - the corresponding minimum frame size is 
L2_HDR_LEN + 9728 + L2_CRC_LEN = 9746 bytes, which is larger than the NIC can 
accommodate (note that 9728 is the largest L2 frame size allowed by the NIC, 
not the largest IP packet size).



>+PMD_INIT_LOG(ERR, "Mtu should be between 
>VIRTIO_MIN_RX_BUFSIZE and

>VIRTIO_MAX_RX_PKTLEN \n");



Two things on this statement:

1) in the context of a log message, VIRTIO_XXX_RX_BUFSIZE most likely means 
very little, and as such is not helpful. I suggest going with the format that I 
included in my earlier mail, which prints the numeric value of the min and max 
rx defines

2)  MTU is an initialization, and should be printed as such in a log 
(i.e. all caps) 



Hope this helps,

Mark



>+return -EINVAL;

>+  }

>+  return 0;

>+}

>+

> /*

> 

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Mark,

Yes I thought I did that change. Sorry once again.. making too many mistakes. 
Changed it . Thanks. 
The MTU here is L3 MTU.  Setting this will help in reducing the 
fragmented/multi-segmented packets and also in case we want to reduce the MTU 
below 1500, to support VXLAN or GRE tunnel for the packets in openstack and 
cloud environments.  

---
 drivers/net/virtio/virtio_ethdev.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..da16ad4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c

static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev,
@@ -652,6 +653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
 }

+static int
+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "Mtu should be between VIRTIO_MIN_RX_BUFSIZE 
and VIRTIO_MAX_RX_PKTLEN \n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.promiscuous_disable = virtio_dev_promiscuous_disable,
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
--

--
Regards,
Souvik
-Original Message-
From: Kavanagh, Mark B [mailto:mark.b.kavan...@intel.com] 
Sent: Friday, September 9, 2016 11:05 AM
To: Dey, Souvik ; Yuanhan Liu 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: RE: [PATCH v4]net/virtio: add mtu set in virtio

>
>Hi Liu,
>
>Yes agreed your comment. I will definitely remove the declaration as it 
>is not really required.
> So the latest patch will look like this . Yes I did rush a bit to 
>submit the patch last will correct my suite. So sending the patch in a 
>reply if we have more comments we can take a look and they re-submit the final 
>reviewed patch. Thanks for the help though.
>
>---
> drivers/net/virtio/virtio_ethdev.c | 12 
> 1 file changed, 12 insertions(+)
>
>diff --git a/drivers/net/virtio/virtio_ethdev.c 
>b/drivers/net/virtio/virtio_ethdev.c
>index 07d6449..da16ad4 100644
>--- a/drivers/net/virtio/virtio_ethdev.c
>+++ b/drivers/net/virtio/virtio_ethdev.c
>
>+static int
>+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
>+  struct virtio_hw *hw = dev->data->dev_private;
>+  if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
>+  PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

Hi Souvik,

Why hardcode the values in the PMD_INIT_LOG?

Why not  do the following: PMD_INIT_LOG(ERR, "MTU should be between %d and %d", 
 VIRTIO_MIN_RX_BUFSIZE,
VIRTIO_MAX_RX_PKTLEN);

That way, if the values that the macros evaluate to change, the log will update 
correspondingly.

Also, does 'MTU' in this context relate to the L2 or L3 MTU?

>+  return -EINVAL;
>+  }
>+  return 0;
>+}
>+
> /*
>  * dev_ops for virtio, bare necessities for basic operation
>  */
>@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
>   .promiscuous_disable = virtio_dev_promiscuous_disable,
>   .allmulticast_enable = virtio_dev_allmulticast_enable,
>   .allmulticast_disable= virtio_dev_allmulticast_disable,
>+  .mtu_set = virtio_mtu_set,
>
>   .dev_infos_get   = virtio_dev_info_get,
>   .stats_get       = virtio_dev_stats_get,
>--
>
>--
>Regards,
>Souvik
>
>-Original Message-
>From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
>Sent: Friday, September 9, 2016 3:00 AM
>To: Dey, Souvik 
>Cc: dev at dpdk.org; stephen at networkplumber.org
>Subject: Re: [PATCH v4]net/virtio: add mtu set in virtio
>
>On Wed, Sep 07, 2016 at 04:21:30AM +, Dey, Souvik wrote:
>> Hi Liu,
>>  Submitted the version 4 of the patch as you suggested ,
>
>Your patch is looking much better. But not really, you ignored few of my 
>comments.
>
>> and have removed the Reviewed by line.
>> I have still kept the function definition as to follow the same suit 
>> as we have done

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Liu,

Yes agreed your comment. I will definitely remove the declaration as it is not 
really required. 
 So the latest patch will look like this . Yes I did rush a bit to submit the 
patch last will correct my suite. So sending the patch in a reply if we have 
more comments we can take a look and they re-submit the final reviewed patch. 
Thanks for the help though. 

---
 drivers/net/virtio/virtio_ethdev.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..da16ad4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c

+static int
+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.promiscuous_disable = virtio_dev_promiscuous_disable,
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
--

--
Regards,
Souvik

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Friday, September 9, 2016 3:00 AM
To: Dey, Souvik 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [PATCH v4]net/virtio: add mtu set in virtio

On Wed, Sep 07, 2016 at 04:21:30AM +, Dey, Souvik wrote:
> Hi Liu,
>   Submitted the version 4 of the patch as you suggested ,

Your patch is looking much better. But not really, you ignored few of my 
comments.

> and have removed the Reviewed by line.
> I have still kept the function definition as to follow the same suit as we 
> have done for other eth_dev_ops.

That's because most of the method implementions are after the reference, thus 
the declaration is needed.

For your case, I see no good reason to do that. BTW, if you disagree with my 
comment, you shoud made a reply, instead of rushing to sending a new version.

> --
> Regards,
> Souvik
> 
> -Original Message-
> From: Dey, Souvik
> Sent: Wednesday, September 7, 2016 12:19 AM
> To: dev at dpdk.org; stephen at networkplumber.org; 
> yuanhan.liu at linux.intel.com
> Cc: Dey, Souvik 
> Subject: [PATCH v4]net/virtio: add mtu set in virtio
> 
> 
> Virtio interfaces should also support setting of mtu, as in case of cloud it 
> is expected to have the consistent mtu across the infrastructure that the 
> dhcp server sends and not hardcoded to 1500(default).
> 
> Changes in v4: Incorporated review comments.
> Changes in v3: Corrected few style errors as reported by sys-stv.
> Changes in v2: Incorporated review comments.

DPDK prefers to put the change log to ...
> 
> Signed-off-by: Souvik Dey 
> 
> ---

... here.

So that they will be showed in mailing list (for review), but they will be gone 
after apply. In another word, we don't like to see those change log in git 
history, but we'd like to see them while review.

>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 07d6449..da16ad4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,  
> static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);  
> static void virtio_mac_addr_set(struct rte_eth_dev *dev,
>   struct ether_addr *mac_addr);
> +static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
>  
>  static int virtio_dev_queue_stats_mapping_set(
>   __rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@ 
> virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
>   PMD_INIT_LOG(ERR, "Failed to disable allmulticast");  }
>  
> +static int
> +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> + struct virtio_hw *hw = dev->data->dev_private;
> + if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
> + PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

I still saw those numbers.

--yliu

[dpdk-dev] VLAN of SRIOV VF with DPDK

[Dey, Souvik]

Hi,
  I have having an unique issue to get the VLAN tags upto the VM 
instance running ixgbevf pmd. Currently my setup looks like this :

Host running 7.1 RHEL , linux 3.10.0-229.el7.x86_64 with 10G 82599ES NIC cards 
with firmware : 0x8838 and ixgbe driver version 4.0.1-k-rh7.1

Guest running Debian 7 , linux 3.2.73 with VF attached from the 10G PF. We are 
using DPDK 2.1 on the guest to receive packets and pass it to the linux kernel 
using kni interfaces.

Now, our requirement is to have VLAN come up to the Guest from the outside and 
the Guest should be able to send VLAN packets out too.

We have set hw_vlan_strip to 0 so that the vlan is not stripped by the VF. Also 
we have not configured any VLAN id on the VF, so that the rx vlan filtration is 
not turned on in the HOST.

We have configured only one rx queue and 2 tx queues. With this configuration 
when we send packets from the kernel through kni with VLAN tags , packets are 
getting dropped in the host saying spoofed packets. I have also turned off 
spoofchk off on the VF and then the TX packets were going out. But the RX 
packets were not even reaching the guest.

If I remove my DPDK app and try with normal Debian linux, then we are seeing 
both the TX and RX packets following with proper VLAN tags up to the guest. In 
this case we need not turn of spoofchk on the VF also.

I am performing simple ping test as of now.

Also, I don't see any kni callback when we configure the VLAN on the guest 
which can go down till the Host. I also see that we are not setting the 
software/hardware vfta table at all in the ixgbevf code. Is this required to be 
setup, as I feel the kernel might be doing it .

Any help or pointers to this issue will be of great help.

--
Regards,
Souvik

[dpdk-dev] [PATCH v2] add mtu set in virtio

[Dey, Souvik]

Are we good to get this in for 16.11 and then revisit this when the VHOST 
improvements comes in. This will atleast take care of the gap between 16.11 and 
VHOST improvements coming in.

--
Regards,
Souvik

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Thursday, September 8, 2016 3:57 AM
To: Maxime Coquelin 
Cc: Dey, Souvik ; stephen at networkplumber.org; 
huawei.xie at intel.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio

On Thu, Sep 08, 2016 at 09:50:34AM +0200, Maxime Coquelin wrote:
> 
> 
> On 09/08/2016 09:30 AM, Yuanhan Liu wrote:
> >On Wed, Sep 07, 2016 at 11:16:47AM +0200, Maxime Coquelin wrote:
> >>
> >>
> >>On 09/07/2016 05:25 AM, Yuanhan Liu wrote:
> >>>On Tue, Aug 30, 2016 at 09:57:39AM +0200, Maxime Coquelin wrote:
> >>>>Hi Souvik,
> >>>>
> >>>>On 08/30/2016 01:02 AM, souvikdey33 wrote:
> >>>>>Signed-off-by: Souvik Dey 
> >>>>>
> >>>>>Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey 
> >>>>>")
> >>>>>Reviewed-by: Stephen Hemminger 
> >>>>>
> >>>>>Virtio interfaces should also support setting of mtu, as in case 
> >>>>>of cloud it is expected to have the consistent mtu across the 
> >>>>>infrastructure that the dhcp server sends and not hardcoded to 
> >>>>>1500(default).
> >>>>>---
> >>>>>drivers/net/virtio/virtio_ethdev.c | 12 
> >>>>>1 file changed, 12 insertions(+)
> >>>>
> >>>>FYI, there are some on-going changes in the VIRTIO specification 
> >>>>so that the VHOST interface exposes its MTU to its VIRTIO peer.
> >>>>It may also be used as an alternative of what you patch achieves.
> >>>>
> >>>>I am working on its implementation in Qemu/DPDK, our goal being to 
> >>>>reduce performance drops for small packets with Rx mergeable 
> >>>>buffers feature enabled.
> >>>
> >>>Mind to educate me a bit on how that works?
> >>
> >>Of course.
> >>
> >>Basically, this is a way to advise the MTU we want in the guest.
> >>In the guest, if GRO is not enabled:
> >> - In case of Kernel virtio-net, it could be used to size the SKBs 
> >>at the expected MTU. If possible, we could disable Rx mergeable 
> >>buffers.
> >> - In case of virtio PMD, if the MTU advised by host is lower than 
> >>the pre-allocated mbuf size for the receive queue, then we should 
> >>not need mergeable buffers.
> >
> >Thanks for the explanation!
> >
> >I see. So, the point is to avoid using mergeable buffers while it is 
> >enabled.
> >
> >>Does that sound reasonnable?
> >
> >Yeah, maybe. Just don't know how well it may work in real life. Have 
> >you got any rought data so far?
> 
> The PoC is not done yet, only Qemu part is implemented.
> But what we noticed is that for small packets, we have a 50% 
> degradation when rx mergeable buffers are on when running PVP 
> use-case.
> 
> Main part of the degradation is due an additional cache-miss in 
> virtio-pmd receive path, because we fetch the header to get the number 
> of buffer.
> 
> When sending only small packets and removing this access, we recover 
> 25% of the degradation.
> 
> The 25% remaining part may be reduced significantly with Zhihong series.
> 
> Hope it answer your questions.

Yes, it does and thanks for the info.

--yliu

[dpdk-dev] [PATCH v4]net/virtio: add mtu set in virtio

[Dey, Souvik]

Hi Liu,
Submitted the version 4 of the patch as you suggested , and have 
removed the Reviewed by line.
I have still kept the function definition as to follow the same suit as we have 
done for other eth_dev_ops.

--
Regards,
Souvik

-Original Message-
From: Dey, Souvik 
Sent: Wednesday, September 7, 2016 12:19 AM
To: dev at dpdk.org; stephen at networkplumber.org; yuanhan.liu at 
linux.intel.com
Cc: Dey, Souvik 
Subject: [PATCH v4]net/virtio: add mtu set in virtio


Virtio interfaces should also support setting of mtu, as in case of cloud it is 
expected to have the consistent mtu across the infrastructure that the dhcp 
server sends and not hardcoded to 1500(default).

Changes in v4: Incorporated review comments.
Changes in v3: Corrected few style errors as reported by sys-stv.
Changes in v2: Incorporated review comments.

Signed-off-by: Souvik Dey 

---
 drivers/net/virtio/virtio_ethdev.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..da16ad4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,  
static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);  
static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);

 static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev, @@ -652,6 +653,16 @@ 
virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");  }

+static int
+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
+   struct virtio_hw *hw = dev->data->dev_private;
+   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
+   PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");
+   return -EINVAL;
+   }
+   return 0;
+}
+
 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.promiscuous_disable = virtio_dev_promiscuous_disable,
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
--
2.9.3.windows.1

[dpdk-dev] [PATCH v3]virtio:add mtu set in virtio

[Dey, Souvik]

Ok thanks understood. I will submit v4 for this.

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Tuesday, September 6, 2016 11:54 PM
To: Dey, Souvik 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v3]virtio:add mtu set in virtio

On Wed, Sep 07, 2016 at 03:47:27AM +, Dey, Souvik wrote:
> Ok will change it. Do I need to submit a new v4 for that ?

Yes.

> can I put your name also in the reviewed by list?

Nope, you should not add that. I just offered some comments. And yes, I 
reviewed your patch, but that doesn't mean you could add my Reviewed-by.

You can only add the Reviewed-by tag only when the reviewer gave it to you, 
explicitly, like following:

Reviewed-by: Some One 

--yliu

> 
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Tuesday, September 6, 2016 11:43 PM
> To: Dey, Souvik 
> Cc: dev at dpdk.org; stephen at networkplumber.org
> Subject: Re: [dpdk-dev] [PATCH v3]virtio:add mtu set in virtio
> 
> On Tue, Sep 06, 2016 at 11:21:56PM -0400, souvikdey33 wrote:
> > +static int
> > +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> > +   struct virtio_hw *hw = dev->data->dev_private;
> > +   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
> > +   PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");
> 
> I forgot to mention in last email, that you should not use the number (64 and 
> 9728) directly, use the MACRO instead.
> 
>   --yliu

[dpdk-dev] [PATCH v3]virtio:add mtu set in virtio

[Dey, Souvik]

Ok will change it. Do I need to submit a new v4 for that ? can I put your name 
also in the reviewed by list?

-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Tuesday, September 6, 2016 11:43 PM
To: Dey, Souvik 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v3]virtio:add mtu set in virtio

On Tue, Sep 06, 2016 at 11:21:56PM -0400, souvikdey33 wrote:
> +static int
> +virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) {
> + struct virtio_hw *hw = dev->data->dev_private;
> + if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
> + PMD_INIT_LOG(ERR, "Mtu should be between 64 and 9728\n");

I forgot to mention in last email, that you should not use the number (64 and 
9728) directly, use the MACRO instead.

--yliu

[dpdk-dev] [PATCH v3]virtio:add mtu set in virtio

[Dey, Souvik]

Hi Liu,


The first version of the patch was reviewed by Stephen and after he agreed I 
have incorporated all those changes in v2 and v3 had only the style error 
fixes. That is why I have put the line Reviewed by .
Still I might have some errors in filing the patch as I am new to this. Do you 
recommend to submit an updated version or this is fine ? 

--
Regards,
Souvik
-Original Message-
From: Yuanhan Liu [mailto:yuanhan@linux.intel.com] 
Sent: Tuesday, September 6, 2016 11:38 PM
To: Dey, Souvik 
Cc: dev at dpdk.org; stephen at networkplumber.org
Subject: Re: [dpdk-dev] [PATCH v3]virtio:add mtu set in virtio

Firstly, thanks for the patch!

And I got few more style issues for you :) The first goes to the subject 
(commit summary):

- the prefix is "net/virtio", but not "virtio"

- a space is needed after ':'

On Tue, Sep 06, 2016 at 11:21:56PM -0400, souvikdey33 wrote:
> Signed-off-by: Souvik Dey 

SoB should go the end of the commit log.

> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey ")

The fixline is needed for bug fixing patch only. Besides that, the commit has 
to be an commit has been applied before.

> Reviewed-by: Stephen Hemminger 

I don't see such Reviewed-by from Stephen. I think you should not add it, 
unless someone has given you that, explicitly.

> Virtio interfaces should also support setting of mtu, as in case of 
> cloud it is expected to have the consistent mtu across the 
> infrastructure that the dhcp server sends and not hardcoded to 1500(default).
> ---
> Corrected few style errors as reported by sys-stv.

It's better to keep old changes, such as:

v3: correct few style errors ...

v2: 

FYI, you might want to read others patch to get more used to the right way of 
making a patch.

> 
>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 07d6449..da16ad4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev 
> *dev,  static void virtio_mac_addr_remove(struct rte_eth_dev *dev, 
> uint32_t index);  static void virtio_mac_addr_set(struct rte_eth_dev *dev,
>   struct ether_addr *mac_addr);
> +static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);

I think it's not necessary if you defined the function before the usage.

--yliu

[dpdk-dev] [PATCH v2] add mtu set in virtio

[Dey, Souvik]

Hi Maxime,
In that case let this fix be there till the time the new implementation 
comes in. We can re-visit the changes again in the new implementation and then 
decide to keep this or remove it. Hope this serves all the purposes.

--
Regards,
Souvik

-Original Message-
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] 
Sent: Friday, September 2, 2016 3:06 AM
To: Dey, Souvik ; stephen at networkplumber.org
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio

Hi Souvik,

On 09/02/2016 12:20 AM, Dey, Souvik wrote:
> Hi Maxime,
>   When is patches or new implementation going to come in the release ? if 
> it is not 16.11 then, can we keep this change till the new virtio changes 
> come in the release. And if it is already planned for 16.11, then can I get a 
> little more information on that.
>
I'm currently working on qemu part implementation, first RFC should be sent 
next week.

Goal is to have it in 16.11, but I cannot commit, as the spec update has not 
been acked yet.

For more information, you can start by having a look at the spec review:
https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html

Regards,
Maxime

> --
> Regards,
> Souvik
>
> -Original Message-
> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com]
> Sent: Tuesday, August 30, 2016 3:58 AM
> To: Dey, Souvik ; stephen at networkplumber.org; 
> huawei.xie at intel.com; yuanhan.liu at linux.intel.com
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio
>
> Hi Souvik,
>
> On 08/30/2016 01:02 AM, souvikdey33 wrote:
>> Signed-off-by: Souvik Dey 
>>
>> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey 
>> ")
>> Reviewed-by: Stephen Hemminger 
>>
>> Virtio interfaces should also support setting of mtu, as in case of 
>> cloud it is expected to have the consistent mtu across the 
>> infrastructure that the dhcp server sends and not hardcoded to 1500(default).
>> ---
>>  drivers/net/virtio/virtio_ethdev.c | 12 
>>  1 file changed, 12 insertions(+)
>
> FYI, there are some on-going changes in the VIRTIO specification so that the 
> VHOST interface exposes its MTU to its VIRTIO peer.
> It may also be used as an alternative of what you patch achieves.
>
> I am working on its implementation in Qemu/DPDK, our goal being to reduce 
> performance drops for small packets with Rx mergeable buffers feature enabled.
>
> Regards,
> Maxime
>

[dpdk-dev] [PATCH v2] add mtu set in virtio

[Dey, Souvik]

Hi Maxime,
When is patches or new implementation going to come in the release ? if 
it is not 16.11 then, can we keep this change till the new virtio changes come 
in the release. And if it is already planned for 16.11, then can I get a little 
more information on that.

--
Regards,
Souvik

-Original Message-
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] 
Sent: Tuesday, August 30, 2016 3:58 AM
To: Dey, Souvik ; stephen at networkplumber.org; 
huawei.xie at intel.com; yuanhan.liu at linux.intel.com
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio

Hi Souvik,

On 08/30/2016 01:02 AM, souvikdey33 wrote:
> Signed-off-by: Souvik Dey 
>
> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey ")
> Reviewed-by: Stephen Hemminger 
>
> Virtio interfaces should also support setting of mtu, as in case of 
> cloud it is expected to have the consistent mtu across the 
> infrastructure that the dhcp server sends and not hardcoded to 1500(default).
> ---
>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)

FYI, there are some on-going changes in the VIRTIO specification so that the 
VHOST interface exposes its MTU to its VIRTIO peer.
It may also be used as an alternative of what you patch achieves.

I am working on its implementation in Qemu/DPDK, our goal being to reduce 
performance drops for small packets with Rx mergeable buffers feature enabled.

Regards,
Maxime

[dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

[Dey, Souvik]

Yes this patch definitely solves my issue too. 

-Original Message-
From: Mcnamara, John [mailto:john.mcnam...@intel.com] 
Sent: Thursday, September 1, 2016 7:00 AM
To: Mussar, Gary ; Dey, Souvik ; 
Stephen Hemminger 
Cc: nhorman at tuxdriver.com; dev at dpdk.org
Subject: RE: [dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mussar, Gary
> Sent: Monday, August 29, 2016 4:10 PM
> To: Dey, Souvik ; Stephen Hemminger 
> 
> Cc: nhorman at tuxdriver.com; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface 
> issue.
> 
> We did this slightly differently. This is 100% python and is a bit 
> more general. We search for the first "net" directory under the 
> specific device directory.
> 
> ---
> --- tools/dpdk-devbind.py   2016-08-29 11:02:35.594202888 -0400
> +++ ../dpdk/tools/dpdk-devbind.py 2016-08-29 11:00:34.897677233 -0400
> @@ -221,11 +221,11 @@
>  name = name.strip(":") + "_str"
>  device[name] = value
>  # check for a unix interface name
> -sys_path = "/sys/bus/pci/devices/%s/net/" % dev_id
> -if exists(sys_path):
> -device["Interface"] = ",".join(os.listdir(sys_path))
> -else:
> -device["Interface"] = ""
> +device["Interface"] = ""
> +for base, dirs, files in os.walk("/sys/bus/pci/devices/%s/" %
> dev_id):
> +if "net" in dirs:
> +device["Interface"] =
> ",".join(os.listdir(os.path.join(base,"net")))
> +break
>  # check if a port is used for ssh connection
>  device["Ssh_if"] = False
>  device["Active"] = ""
> ---

Hi Gary,

That looks like a cleaner solution. Could you submit that as a patch.

Souvik, could you test this patch and confirm it fixes your issue.


Gary, if you submit a patch could you make a few minor changes:

> +device["Interface"] = ""
> +for base, dirs, files in os.walk("/sys/bus/pci/devices/%s/" % dev_id):
> +

If "files" is unused, and it looks like it is, then replace it with "_".


> +device["Interface"] = 
> + ",".join(os.listdir(os.path.join(base,"net")))

There is a space required after "," for PEP8 compliance.

John

[dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

[Dey, Souvik]

Hi,

I already followed the 100% python way and submitted the v3 of this patch. 
http://dpdk.org/dev/patchwork/patch/15378/
How will your patch be different in solving the issue. There will always be 
multiple ways to solving things right.


V3 of my submitted patch:

diff --git a/tools/dpdk-devbind.py b/tools/dpdk-devbind.py
index b69ca2a..c0b46ee 100755
--- a/tools/dpdk-devbind.py
+++ b/tools/dpdk-devbind.py
@@ -36,6 +36,7 @@  import sys
 import os
 import getopt
 import subprocess
+
 from os.path import exists, abspath, dirname, basename

 # The PCI base class for NETWORK devices
@@ -222,8 +223,19 @@  def get_pci_device_details(dev_id):
 device[name] = value
 # check for a unix interface name
 sys_path = "/sys/bus/pci/devices/%s/net/" % dev_id
+# the path for virtio devices are different, so get the correct path
+virtio = "/sys/bus/pci/devices/%s/" % dev_id
+ls = subprocess.Popen(['ls', virtio], stdout=subprocess.PIPE)
+grep = subprocess.Popen('grep virt'.split(), stdin=ls.stdout,
+stdout=subprocess.PIPE)
+ls.stdout.close()
+virtio = grep.communicate()[0].rstrip()
+ls.wait()
+virtio_sys_path = "/sys/bus/pci/devices/%s/%s/net/" % (dev_id, virtio)
 if exists(sys_path):
 device["Interface"] = ",".join(os.listdir(sys_path))
+elif exists(virtio_sys_path):
+device["Interface"] = ",".join(os.listdir(virtio_sys_path))
 else:
 device["Interface"] = ""
 # check if a port is used for ssh connection


-Original Message-
From: Mussar, Gary [mailto:gmus...@ciena.com] 
Sent: Monday, August 29, 2016 11:10 AM
To: Dey, Souvik ; Stephen Hemminger 
Cc: nhorman at tuxdriver.com; dev at dpdk.org
Subject: RE: [dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

We did this slightly differently. This is 100% python and is a bit more 
general. We search for the first "net" directory under the specific device 
directory.

---
--- tools/dpdk-devbind.py   2016-08-29 11:02:35.594202888 -0400
+++ ../dpdk/tools/dpdk-devbind.py 2016-08-29 11:00:34.897677233 -0400
@@ -221,11 +221,11 @@
 name = name.strip(":") + "_str"
 device[name] = value
 # check for a unix interface name
-sys_path = "/sys/bus/pci/devices/%s/net/" % dev_id
-if exists(sys_path):
-device["Interface"] = ",".join(os.listdir(sys_path))
-else:
-device["Interface"] = ""
+device["Interface"] = ""
+for base, dirs, files in os.walk("/sys/bus/pci/devices/%s/" % dev_id):
+if "net" in dirs:
+device["Interface"] = 
",".join(os.listdir(os.path.join(base,"net")))
+    break
 # check if a port is used for ssh connection
 device["Ssh_if"] = False
 device["Active"] = ""
---

Gary

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dey, Souvik
Sent: Friday, August 26, 2016 8:21 PM
To: Stephen Hemminger
Cc: nhorman at tuxdriver.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

Hi ,
        I have already updated it and have re submitted the patch v3. Can you 
please check that http://dpdk.org/dev/patchwork/patch/15378/
--
Regards,
Souvik

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Friday, August 26, 2016 11:55 AM
To: Dey, Souvik 
Cc: nhorman at tuxdriver.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

On Wed, 24 Aug 2016 22:25:46 -0400
souvikdey33  wrote:

> +#The path for virtio devices are different. Get the correct path.
> + virtio = "/sys/bus/pci/devices/%s/" % dev_id
> +cmd = " ls %s | grep 'virt' " %virtio
> +virtio = commands.getoutput(cmd)
> +virtio_sys_path = "/sys/bus/pci/devices/%s/%s/net/" % 
> +(dev_id,virtio)
>  if exists(sys_path):
>  device["Interface"] = ",".join(os.listdir(sys_path))

There should be a way to do this in python without going out to shell.
This would be safer and more secure.

The code already uses os.listdir() (which is the python library version of ls) 
in later section. Why not use that here to check for virtio bus.

[dpdk-dev] [PATCH v1] add mtu set in virtio

[Dey, Souvik]

Thanks , I will remove the unlikely from the conditionally statement.
Below is the complete patch :

>From 2e4b391fe90ba5e617611e341a7d260dd3dd9144 Mon Sep 17 00:00:00 2001
From: souvikdey33 
Date: Fri, 26 Aug 2016 20:46:21 -0400
Subject: [PATCH v2 2/3] Signed-off-by: Souvik Dey 

Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey ")
Reviewed-by: Stephen Hemminger 

Virtio interfaces should also support setting of mtu, as in case of cloud
it is expected to have the consistent mtu across the infrastructure that
the dhcp server sends and not hardcoded to 1500(default).
---
 drivers/net/virtio/virtio_ethdev.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 07d6449..da16ad4 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -92,6 +92,7 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,
 static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);
 static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
+static int  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);

 static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev,
@@ -652,6 +653,16 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "Failed to disable allmulticast");
 }

+static int 
+virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) 
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   if (mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN) {
+  PMD_INIT_LOG(ERR,"Mtu should be between 64 and 9728."
+  return -EINVAL;
+   }
+   return 0;
+}
+
 /*
  * dev_ops for virtio, bare necessities for basic operation
  */
@@ -664,6 +675,7 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
.promiscuous_disable = virtio_dev_promiscuous_disable,
.allmulticast_enable = virtio_dev_allmulticast_enable,
.allmulticast_disable= virtio_dev_allmulticast_disable,
+   .mtu_set = virtio_mtu_set,

.dev_infos_get   = virtio_dev_info_get,
.stats_get   = virtio_dev_stats_get,
-- 
2.9.3.windows.1

As I am submitting to DPDK for the first time can you please guide with the 
next steps.

--
Regards,
Souvik

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Monday, August 29, 2016 3:33 PM
To: Dey, Souvik 
Cc: huawei.xie at intel.com; yuanhan.liu at linux.intel.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] add mtu set in virtio

On Sun, 28 Aug 2016 22:43:54 +
"Dey, Souvik"  wrote:

> Hi ,
>   Currently as you have mentioned, I have changed the code to:
> static int
>  virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)  {
> struct virtio_hw *hw = dev->data->dev_private;
> -   if (unlikely(mtu < (uint32_t)hw->vtnet_hdr_size + ETHER_HDR_LEN)) {
> -   return -1;
> +   if (unlikely(mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN)) {
> +PMD_INIT_LOG(ERR,"Mtu should be between 64 and 9728."
> +   return -EINVAL;
> }
> return 0;
>  }
> 
> Yes, we should support till 64K as the kernel does , but I need to go through 
> the changes and test it properly before submitting it for review. Moreover I 
> was thinking with the changes in the mtu, we should also support 
> multi-segment buffers in kni. What do you suggest ?

This looks good, but you really don't need likely/unlikely in this code.
It is not at all performance critical.

[dpdk-dev] [PATCH v1] add mtu set in virtio

[Dey, Souvik]

Hi ,
Currently as you have mentioned, I have changed the code to:
static int 
 virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) 
 {
struct virtio_hw *hw = dev->data->dev_private;
-   if (unlikely(mtu < (uint32_t)hw->vtnet_hdr_size + ETHER_HDR_LEN)) {
-   return -1;
+   if (unlikely(mtu < VIRTIO_MIN_RX_BUFSIZE || mtu > VIRTIO_MAX_RX_PKTLEN)) {
+  PMD_INIT_LOG(ERR,"Mtu should be between 64 and 9728."
+   return -EINVAL;
}
return 0;
 }

Yes, we should support till 64K as the kernel does , but I need to go through 
the changes and test it properly before submitting it for review. Moreover I 
was thinking with the changes in the mtu, we should also support multi-segment 
buffers in kni. What do you suggest ?

--
Regards,
Souvik

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Saturday, August 27, 2016 8:16 PM
To: Dey, Souvik 
Cc: huawei.xie at intel.com; yuanhan.liu at linux.intel.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] add mtu set in virtio

On Fri, 26 Aug 2016 20:54:28 -0400
souvikdey33  wrote:

> This functionality is required mostly in the cloud infrastructure.
> For example, if we use gre or vxlan network between compute and 
> controller, then we should not use 1500 mtu in the guest as with 
> encapsulation the sixe of the packet will be more and will get dropped 
> in the infrastructure. So, in that case we should honor the mtu size 
> sent by the dhcp server and configure the same on the virtual 
> interfaces in the guest. This will also keep a consistent mtu through 
> out the infrastructure.
> 
> souvikdey33 (1):
>   Signed-off-by: Souvik Dey 
> 
>  drivers/net/virtio/virtio_ethdev.c | 12 
>  1 file changed, 12 insertions(+)
> 

Thanks for the patch, it is a good step forward but it looks like more code is 
needed to do this safely. At a minimum, need to check that MTU is not greater 
than VIRTIO_MAX_RX_PKTLEN.
And error return should be negative errno not -1.

Something like:
   if (mtu < VIRTIO_MIN_MTU || mtu > VIRTIO_MAX_RX_PKTLEN)
return -EINVAL;

Looking at Linux driver, it allows MTU of up to 64K, yet DPDK only allows 9728. 
 That should probably be fixed.

[dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

[Dey, Souvik]

Hi ,
I have already updated it and have re submitted the patch v3. Can you 
please check that http://dpdk.org/dev/patchwork/patch/15378/
--
Regards,
Souvik

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Friday, August 26, 2016 11:55 AM
To: Dey, Souvik 
Cc: nhorman at tuxdriver.com; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] dpdk-devbind.py: Virtio interface issue.

On Wed, 24 Aug 2016 22:25:46 -0400
souvikdey33  wrote:

> +#The path for virtio devices are different. Get the correct path.
> + virtio = "/sys/bus/pci/devices/%s/" % dev_id
> +cmd = " ls %s | grep 'virt' " %virtio
> +virtio = commands.getoutput(cmd)
> +virtio_sys_path = "/sys/bus/pci/devices/%s/%s/net/" % 
> +(dev_id,virtio)
>  if exists(sys_path):
>  device["Interface"] = ",".join(os.listdir(sys_path))

There should be a way to do this in python without going out to shell.
This would be safer and more secure.

The code already uses os.listdir() (which is the python library version of ls) 
in later section. Why not use that here to check for virtio bus.

[dpdk-dev] VLAN with ixgbevf pmd

[Dey, Souvik]

Hi Lu,

  I already have the hw_vlan_filter set to 0 to disable it in the 
port_conf .



struct rte_eth_conf port_conf =

{

.rxmode = {

.split_hdr_size = 0,

.header_split   = 0, /**< Header Split disabled */

.hw_ip_checksum = 0, /**< IP checksum offload disabled */

.hw_vlan_filter = 0, /**< VLAN filtering disabled */

.jumbo_frame= 0, /**< Jumbo Frame Support disabled */

.hw_strip_crc   = 0, /**< CRC stripped by hardware */

},

.txmode = {

.mq_mode = ETH_MQ_TX_NONE,

},

.intr_conf = {

.lsc = 0, /**< lsc interrupt feature enabled */

},

#if 0

.rx_adv_conf = {

.rss_conf = {

.rss_key = NULL,

.rss_hf = ETH_RSS_IPV4 | ETH_RSS_IPV6,

},

}

#endif

};



Interestingly the same setup works fine with vlan without Dpdk. Any other 
suggestions ?



--

Regards,

Souvik



-Original Message-
From: Lu, Wenzhuo [mailto:wenzhuo...@intel.com]
Sent: Thursday, August 18, 2016 8:33 PM
To: Dey, Souvik ; dev at dpdk.org
Subject: RE: VLAN with ixgbevf pmd



Hi Souvik,

Take testpmd for example, normally we should disable HW vlan filter by adding 
parameter " --disable-hw-vlan-filter " or CLI " port config all hw-vlan-filter 
off". Hope it can help :)





Best regards

Wenzhuo Lu





> -Original Message-

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dey, Souvik

> Sent: Thursday, August 18, 2016 10:47 PM

> To: dev at dpdk.org<mailto:dev at dpdk.org>

> Subject: [dpdk-dev] VLAN with ixgbevf pmd

>

> Hi,

>

>

>

> I am trying to get tagged packets to work in SRIOV mode.  I am using

> dpdk  2.1 version with an application on KVM.

>

>  The setup is as below: The same configuration works for untagged packets.

>

>  Guest VM (Virtual Function/Created tagged kni interfaces)--- > KVM

> host (PF/no tag on the VF ) -->Client server

>

>  When the packet is tagged (vlan tag/id) the packet is sent from kni

> interface to the application is it received with the tag and is also

> sent out to the pmd. But the packets does not go out of the host.

> Neither any tagged packets are coming in from out to the application. The 
> ol_flags is set to 0 in my application.

>

> Can someone let me know what I am missing? Do we need to do some

> specific configuration on the rx or tx ports for this ? Does the vlan

> id configured on the kni gets peculated down to the vf of the host too which 
> is causing the issue ?

>

>

>

> Any help would be highly appreciated!

>

>

>

> --

>

> Regards,

>

> Souvik

[dpdk-dev] VLAN with ixgbevf pmd

[Dey, Souvik]

Hi,



I am trying to get tagged packets to work in SRIOV mode.  I am using dpdk  2.1 
version with an application on KVM.

 The setup is as below: The same configuration works for untagged packets.

 Guest VM (Virtual Function/Created tagged kni interfaces)--- > KVM host (PF/no 
tag on the VF ) -->Client server

 When the packet is tagged (vlan tag/id) the packet is sent from kni interface 
to the application is it received with the tag and is also sent out to the pmd. 
But the packets does not go out of the host. Neither any tagged packets are 
coming in from out to the application. The ol_flags is set to 0 in my 
application.

Can someone let me know what I am missing? Do we need to do some specific 
configuration on the rx or tx ports for this ? Does the vlan id configured on 
the kni gets peculated down to the vf of the host too which is causing the 
issue ?



Any help would be highly appreciated!



--

Regards,

Souvik

[dpdk-dev] tx_burst errors seen with virtual pmds

[Dey, Souvik]

So is there no resolution to this issue ?

-Original Message-
From: Tan, Jianfeng [mailto:jianfeng@intel.com] 
Sent: Thursday, January 07, 2016 2:18 PM
To: Dey, Souvik ; dev at dpdk.org
Subject: RE: tx_burst errors seen with virtual pmds


Hi Souvik,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dey, Souvik
> Sent: Thursday, January 7, 2016 2:15 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] tx_burst errors seen with virtual pmds
> 
> Hi All,
> While trying call load with virtio_pmd/vmxnet3_pmd , I 
> am seeing that at around 100Mbps, we are having tx_burst errors. We 
> are currently using DPDK 2.1 and send 1 packet at a time. When we try 
> the same with ixgbe_vf we are not seeing similar drops. Is there any 
> issues with the virtual pmds which is causing  this tx drops. We are 
> using tx descriptor as 1024 and 1 tx queue to send out packets.
> 
> --
> Regards,
> Souvik

IMO, for virtio and vmxnet3, there's a frontend in guest and a backend in host.
And mostly, backend driver does the data copies, which spends more CPU than 
frontend. So the tx descriptor queue could be always full, which leads to tx 
error.

Thanks,
Jianfeng

[dpdk-dev] tx_burst errors seen with virtual pmds

[Dey, Souvik]

Hi All,
While trying call load with virtio_pmd/vmxnet3_pmd , I am 
seeing  that at around 100Mbps, we are having tx_burst errors. We are currently 
using DPDK 2.1 and send 1 packet at a time. When we try the same with ixgbe_vf 
we are not seeing similar drops. Is there any issues with the virtual pmds 
which is causing  this tx drops. We are using tx descriptor as 1024 and 1 tx 
queue to send out packets.

--
Regards,
Souvik

[dpdk-dev] Vmxnet3 activation of device fails in DPDK1.7

[Dey, Souvik]

Thanks for the update. Yes I tried with both 1024 and 2048 it worked fine. But 
interestingly 4096 is working fine in ESXi6.0. Are you aware of some 
configuration in ESXi which can solve it issue or bring back nb_rx_desc to max 
of 4096 ?. Or any idea of any fixes from vmware which fixes this issue ?

-Original Message-
From: Yong Wang [mailto:yongw...@vmware.com] 
Sent: Monday, December 14, 2015 11:57 AM
To: Dey, Souvik ; dev at dpdk.org
Subject: Re: [dpdk-dev] Vmxnet3 activation of device fails in DPDK1.7

nb_rx_desc should be less or equal to 2048 in update 3 due to a change in 
vmxnet3 backend. More details can be found at http://kb.vmware.com/kb/2136932.


On 12/13/15, 9:01 PM, "Dey, Souvik"  wrote:

>Not sure about but it definitely worked in ESXi5.5 Update1, and also prior 
>versions. Also on ESXi6.0 it works fine. 
>We are using 1rx queue and 8 tx queues per port. The nb_rx_desc  is set to 
>4096  and the each mbuf size is set to 2048. The rx_conf struct has the 
>following values during the init time .
>
>static const struct rte_eth_rxconf rx_conf = {
>   .rx_thresh = {
>  .pthresh = RX_PTHRESH,
>  .hthresh = RX_HTHRESH,
>  .wthresh = RX_WTHRESH,
>   },
>};
>
>Do you suspect anything wrong in this ?
>
>-Original Message-
>From: Yong Wang [mailto:yongwang at vmware.com] 
>Sent: Friday, December 11, 2015 12:07 AM
>To: Dey, Souvik ; dev at dpdk.org
>Subject: Re: [dpdk-dev] Vmxnet3 activation of device fails in DPDK1.7
>
>On 12/10/15, 2:22 AM, "dev on behalf of Dey, Souvik" on behalf of sodey at sonusnet.com> wrote:
>
>
>
>>Hi,
>>In DPDK 1.7 , while using the vmxnet3 pmd on vmware Esxi 5.5 
>> update 3 we are seeing that activation of the device fails.
>>
>>status = VMXNET3_READ_BAR1_REG(hw, VMXNET3_REG_CMD); return a non zero 
>>status. Though the normal vmxnet3.ko works fine in the same system. Any idea 
>>if anyone has faced this type of issue.
>>
>>--
>>Regards,
>>Souvik
>
>Did it work for ESXi 5.5 update 2 or some earlier version?
>
>Can you also post the rx ring size you used to config the rx queue?
>In update 3, there are some changes to the max allowed rx ring size for ring1. 
>Even ring1 is not used yet in the pmd, the setup code sets ring1?s size the 
>same as ring0?s.