From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DD634A0577 for ; Mon, 13 Apr 2020 18:04:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 267FF1BF9D; Mon, 13 Apr 2020 18:04:19 +0200 (CEST) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) by dpdk.org (Postfix) with ESMTP id 582391BF9D for ; Mon, 13 Apr 2020 18:04:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1586793856; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=hqni35oYFAtw8Nrf6SsvxgR4/OewsQ1BC8QSb5lX3xw=; b=NrsUo38iRXqgMyruvXTEYsAY88uRxYp7Qr0VFnT/7qeF9jnrPYVip/0Y0TYRsyQJMV4Vjf CkVxoi6rdiygRgaS4NqzVN31fnyjvC/lM25hP+huQPb1GJWSFvR61bQ4MNyCdNsyaPidNa E6Z3r/9XAvlY5PtfFzYrFLGlAqnSHV0= Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2174.outbound.protection.outlook.com [104.47.57.174]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-106-HOLNm8pIPe6j6X73s5JiDQ-1; Mon, 13 Apr 2020 12:04:14 -0400 Received: from DM6PR03MB4777.namprd03.prod.outlook.com (2603:10b6:5:18b::26) by DM6PR03MB5084.namprd03.prod.outlook.com (2603:10b6:5:1ed::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.28; Mon, 13 Apr 2020 16:04:11 +0000 Received: from DM6PR03MB4777.namprd03.prod.outlook.com ([fe80::7cc8:d76f:2733:b128]) by DM6PR03MB4777.namprd03.prod.outlook.com ([fe80::7cc8:d76f:2733:b128%3]) with mapi id 15.20.2900.028; Mon, 13 Apr 2020 16:04:11 +0000 From: "Dey, Souvik" To: "dev@dpdk.org" , "users@dpdk.org" , "beilei.xing@intel.com" CC: "ferruh.yigit@intel.com" , "qi.z.zhang@intel.com" Date: Mon, 13 Apr 2020 12:04:11 -0400 Thread-Topic: i40eVF pmd vlan id handling Thread-Index: AdYRqSRKfHRzyHWkRYKBYVqNQ7hrZw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-originating-ip: [72.70.55.110] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25559cb0-9b72-4d5c-aab4-08d7dfc44e2f x-ms-traffictypediagnostic: DM6PR03MB5084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 037291602B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR03MB4777.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(346002)(39850400004)(366004)(376002)(396003)(66446008)(81156014)(64756008)(66556008)(8936002)(8676002)(186003)(66946007)(76116006)(86362001)(9326002)(478600001)(66476007)(71200400001)(9686003)(5660300002)(26005)(6506007)(2906002)(110136005)(33656002)(52536014)(55016002)(54906003)(316002)(7696005)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n+PUYKyucnM3eBiM6q9fQ0xck2QJ0TKIVf5FAda1hCU1l8MRF70Q9u8hA7OA+r3Ib1JGpy2lt/iHppHxmxTWbeAGZArcK46crTcOCTn/nNuLY8QeWVzS8n4xu3RLLFcdRyQKIC/TGeMus/MhxXLFlNjoMmEANzjWmQTzvlqI1YOGIZ9bvelC2CXoF5840QtFe+hNgbywZ23uZT1XzVf5RPWu2bODfDgmXsqesZCasbU0HL4UWuwBUc1OvL0mgf1SDjcUQhTqRgn9E8XzZsBKjmqR3AAIFUycguXW9Cj7FMhfSPboBVDfWWrZ8qcY0hqynSefjHOLuvXJTFDHTsXln3agJBv0MmBdVHxGW2hm5riy8aW5cAP7CGlYqgA/nu35S+CS7RNS7VCCFsZsxUWg2XILMoblcf/aprE5c9zgNwov/23xIADnbjgqJ6nG5GDK x-ms-exchange-antispam-messagedata: 2KXrAr6tvL+/l96uNzSZ49hiWy6j3Qj1rZUwEhpb4oaNZ9l/AvwOJlQ/b0cm0LfXvpODFgk8rszmCptBB0EPin4rF+TVmO7AYyZqp2WH/0jYj2eHBIDl1YPjAdlSvlM5KBRai1mi3bnhexTfGsXQ2g== x-ms-exchange-transport-forked: True x-mc-unique: HOLNm8pIPe6j6X73s5JiDQ-1 x-originatororg: rbbn.com x-ms-exchange-crosstenant-network-message-id: 25559cb0-9b72-4d5c-aab4-08d7dfc44e2f x-ms-exchange-crosstenant-originalarrivaltime: 13 Apr 2020 16:04:11.2776 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: Y5riqAyxu9I6X8wJtya7BeancKA2Z9Int6aNICOuQFYNzIKLSoOO+zMb56LVXqfA x-ms-exchange-transport-crosstenantheadersstamped: DM6PR03MB5084 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] i40eVF pmd vlan id handling X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" 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, a= nd 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, t= hen we should send VIRTCHNL_OP_DISABLE_VLAN_STRIPPING command to the PF fro= m the guest. With more debugging enabled, when DPDK requests VLAN filtering by sending V= IRTCHNL_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 messa= ge 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 p= ackets 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=3D60 nb-segs=3D1 ETH: src=3D00:10:E0:8D:A7:52 dst=3DFF:FF:FF:FF:FF:FF type=3D0x0806 ARP: hrd=3D1 proto=3D0x0800 hln=3D6 pln=3D4 op=3D1 (ARP Request) sha=3D00:10:E0:8D:A7:52 sip=3D8.8.8.102 tha=3D00:00:00:00:00:00 tip=3D8.8.8.3 As the application requested tagging not be stripped, and the hardware driv= er 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 worki= ng 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 heade= r using the data from TCI in i40e_rxd_to_vlan_tci(), but it is having perfo= rmance 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