[dpdk-dev] net/e1000: advertise offload capabilities for the EM PMD

Message ID 1489156701-185471-1-git-send-email-allain.legacy@windriver.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers

Checks

Context Check Description
ci/Intel-compilation success Compilation OK
ci/checkpatch success coding style OK

Commit Message

Allain Legacy March 10, 2017, 2:38 p.m. UTC
  The hardware offload capabilities are not being advertised for the EM PMD.
Because of this, applications that only enable these features if the device
advertises them will never do so.

Normally this is not an issue since normal packet processing should work
even if hardware offload is not available.  But, in older versions of
Virtual Box the e1000 device emulation (Intel PRO/1000 MT Desktop 82540EM)
assumes that it should enable VLAN stripping even if the driver does not
request it.  This means that any ingress packets that have a VLAN tag will
be stripped.  Since the application did not request to enable VLAN
stripping it is not expecting these packets so they are not processed as
VLAN packets.

Regardless of the Virtual Box issue, the driver should be advertising
supported capabilities as is done in other drivers.

Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
---
 drivers/net/e1000/em_ethdev.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
  

Comments

Wenzhuo Lu March 13, 2017, 3:15 a.m. UTC | #1
Hi,

> -----Original Message-----
> From: Allain Legacy [mailto:allain.legacy@windriver.com]
> Sent: Friday, March 10, 2017 10:38 PM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: [PATCH] net/e1000: advertise offload capabilities for the EM PMD
> 
> The hardware offload capabilities are not being advertised for the EM PMD.
> Because of this, applications that only enable these features if the device
> advertises them will never do so.
> 
> Normally this is not an issue since normal packet processing should work even if
> hardware offload is not available.  But, in older versions of Virtual Box the e1000
> device emulation (Intel PRO/1000 MT Desktop 82540EM) assumes that it should
> enable VLAN stripping even if the driver does not request it.  This means that any
> ingress packets that have a VLAN tag will be stripped.  Since the application did
> not request to enable VLAN stripping it is not expecting these packets so they
> are not processed as VLAN packets.
> 
> Regardless of the Virtual Box issue, the driver should be advertising supported
> capabilities as is done in other drivers.
> 
> Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
  
Ferruh Yigit March 14, 2017, 3:19 p.m. UTC | #2
On 3/13/2017 3:15 AM, Lu, Wenzhuo wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Allain Legacy [mailto:allain.legacy@windriver.com]
>> Sent: Friday, March 10, 2017 10:38 PM
>> To: Lu, Wenzhuo
>> Cc: dev@dpdk.org
>> Subject: [PATCH] net/e1000: advertise offload capabilities for the EM PMD
>>
>> The hardware offload capabilities are not being advertised for the EM PMD.
>> Because of this, applications that only enable these features if the device
>> advertises them will never do so.
>>
>> Normally this is not an issue since normal packet processing should work even if
>> hardware offload is not available.  But, in older versions of Virtual Box the e1000
>> device emulation (Intel PRO/1000 MT Desktop 82540EM) assumes that it should
>> enable VLAN stripping even if the driver does not request it.  This means that any
>> ingress packets that have a VLAN tag will be stripped.  Since the application did
>> not request to enable VLAN stripping it is not expecting these packets so they
>> are not processed as VLAN packets.
>>
>> Regardless of the Virtual Box issue, the driver should be advertising supported
>> capabilities as is done in other drivers.
>>
>> Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
> Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>

Applied to dpdk-next-net/master, thanks.
  

Patch

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4066ef9..e76e34b 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1086,6 +1086,16 @@  static int eth_em_set_mc_addr_list(struct rte_eth_dev *dev,
 	dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
 	dev_info->max_rx_pktlen = em_get_max_pktlen(hw);
 	dev_info->max_mac_addrs = hw->mac.rar_entry_count;
+	dev_info->rx_offload_capa =
+		DEV_RX_OFFLOAD_VLAN_STRIP |
+		DEV_RX_OFFLOAD_IPV4_CKSUM |
+		DEV_RX_OFFLOAD_UDP_CKSUM  |
+		DEV_RX_OFFLOAD_TCP_CKSUM;
+	dev_info->tx_offload_capa =
+		DEV_TX_OFFLOAD_VLAN_INSERT |
+		DEV_TX_OFFLOAD_IPV4_CKSUM  |
+		DEV_TX_OFFLOAD_UDP_CKSUM   |
+		DEV_TX_OFFLOAD_TCP_CKSUM;
 
 	/*
 	 * Starting with 631xESB hw supports 2 TX/RX queues per port.