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 E461AA0577 for ; Mon, 13 Apr 2020 22:04:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0F5601C113; Mon, 13 Apr 2020 22:04:03 +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 ABDC91BF44 for ; Mon, 13 Apr 2020 22:04:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1586808240; 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: in-reply-to:in-reply-to:references:references; bh=k+j53OnHkyZQPWSnwvCMMwL/bTTh8fbSOdGJNBW6bj4=; b=idWxBOvTX+4O+QRbLA3G7c/pIkaJYrkIHJmPcihhA/rM7UjUDHYwgAYQJ3NTMnJ08Z1L5m lXeJwq3ESg6JjikvzplGdkSdQaY22TFNJuv8momAfz5lEmwtwdT0PfIzcTqTxB0VSsujfS bAWLrIpXmZ/OI2nGgWzuKsoy74hl0zY= Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2103.outbound.protection.outlook.com [104.47.58.103]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-zFksYh5cP1W35UvEqcJkxA-1; Mon, 13 Apr 2020 16:03:57 -0400 Received: from DM6PR03MB4777.namprd03.prod.outlook.com (2603:10b6:5:18b::26) by DM6PR03MB4346.namprd03.prod.outlook.com (2603:10b6:5:102::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.24; Mon, 13 Apr 2020 20:03:55 +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 20:03:55 +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 16:03:55 -0400 Thread-Topic: i40eVF pmd vlan id handling Thread-Index: AdYRqSRKfHRzyHWkRYKBYVqNQ7hrZwAI9GPg Message-ID: References: In-Reply-To: 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: 3bd4bc40-ac6e-48ad-39fc-08d7dfe5cb8e x-ms-traffictypediagnostic: DM6PR03MB4346: 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)(396003)(346002)(39850400004)(136003)(376002)(366004)(2906002)(86362001)(55016002)(64756008)(5660300002)(6506007)(66556008)(53546011)(26005)(33656002)(76116006)(110136005)(66476007)(66946007)(66446008)(4326008)(7696005)(316002)(186003)(71200400001)(52536014)(478600001)(81156014)(54906003)(2940100002)(8676002)(9686003)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XTDiGiwWKAlVhHmcEM/MY88+kZFnvw48ihugYlYNk3V1rpzpSOsIIFpT/ieBGUzvU6utKkH74UuhTwqvs9hz7M4soQwRZT4rBR8v0yDAn6KOyjc3gh9Kzl0N9RbjJe/iP8wwHefT0vQWJji2mkj5+L+PfLZuQrmAu6655LA+0vgkxE7tcFrLoTgczax/D5uY3CGDrEz25pEhA2C9ITv0/xV+TtFGewEhHDMcmK7lg5MxBjdyRu1B56odGgUNDk8cKqxX9n5wQtJzUWFgiYw44sCKD6yPNk5SMbexbq8YZTyft/Pql6hea3K0VJszTmzxKV693xXCcJpe1UT37klatbtmjXE0o50us2gjAteUsBDhQjS3Hlfv9jQvGELa4dZ+OKg+P2W8Z4UEDreqh2Z5IAI45pJu18HLbUSjFRIAnKDtGdbi1kWHxxtziw5cQobS x-ms-exchange-antispam-messagedata: 1XbJX9AAMPiq17kAeqHKvF5u3/2B76HiBeGApGtl2iiQDwEiEPD+6UjMoFINzYAvOh/bT5dX3ovJU6ruYPsGBqr1n4cQK7S9/SqPF8sh2Xdra8qeRe5t0Cp1Ymmgp/VGb12NOGipFVsxsZbdjRLx+w== x-ms-exchange-transport-forked: True x-mc-unique: zFksYh5cP1W35UvEqcJkxA-1 x-originatororg: rbbn.com x-ms-exchange-crosstenant-network-message-id: 3bd4bc40-ac6e-48ad-39fc-08d7dfe5cb8e x-ms-exchange-crosstenant-originalarrivaltime: 13 Apr 2020 20:03:55.0525 (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: KttLs3oORAxItuy1MJNFCJUi5CGz6v0Z/qQEcSlbB9ZKFfC3IrAu/fpfwhaAhrR6 x-ms-exchange-transport-crosstenantheadersstamped: DM6PR03MB4346 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: Re: [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" 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 =3D I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_privat= e); 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 =3D (struct virtchnl_vlan_filter_list *)cmd_buffer; vlan_list->vsi_id =3D vf->vsi_res->vsi_id; vlan_list->num_elements =3D 1; vlan_list->vlan_id[0] =3D vlanid; args.ops =3D VIRTCHNL_OP_ADD_VLAN; args.in_args =3D (u8 *)&cmd_buffer; args.in_args_size =3D sizeof(cmd_buffer); args.out_buffer =3D vf->aq_resp; args.out_size =3D I40E_AQ_BUF_SZ; err =3D 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 th= e DPDK app ? -- Regards, Souvik From: Dey, Souvik Sent: Monday, April 13, 2020 12:04 PM To: dev@dpdk.org; users@dpdk.org; beilei.xing@intel.com Cc: ferruh.yigit@intel.com; qi.z.zhang@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, 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