From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A49C9A0C47; Thu, 2 Sep 2021 12:49:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2975A4003E; Thu, 2 Sep 2021 12:49:44 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id DC67E4003C for ; Thu, 2 Sep 2021 12:49:41 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10094"; a="282779273" X-IronPort-AV: E=Sophos;i="5.84,372,1620716400"; d="scan'208";a="282779273" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Sep 2021 03:49:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,372,1620716400"; d="scan'208";a="691324332" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga005.fm.intel.com with ESMTP; 02 Sep 2021 03:49:40 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 2 Sep 2021 03:49:39 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Thu, 2 Sep 2021 03:49:39 -0700 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.49) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Thu, 2 Sep 2021 03:49:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PePUdQ7J0n+iAO3wP806EcDmJmICWVtewyZxY6dfC2PhVswH3sGyn7e/uzkCh7vJ6Lb74wD/arIEkXPAamIfx9gEXw+ti1zaBiW/vrADmpvnNY64o1PxG49HnLAJHsmHrKuNMzw+/JmZnQdcthrLvUB8VvuYEREk0sS878GZBf9g5aTT4lGyaDX7t9bfPH4zRxLQtU/HJDRJAY7SJwvsU2rhoLCC0cxgnHB0aJKcw4xKwGJCMDZ6WiI6haPT2edmn4mwjvcNLn5dethmVAXTqMup3fUkUfgSaFMt7pl/1kDkP2MwiNKG48iKISOCfGbAabyA6NQ/jCsJdaav2eEI1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ygZ9Xi66lq23OVEnQ0EqqatcYip0+q8EL73o6dD9UNw=; b=kNqIVWFZF/cxYCvcpzhXfDFXSikt20F5IJxJveO2vIK5H412FwIZ0Qyw7RXuPVlxr1alQNmwSH/3mGA50eP4BHZ6wgD780DdkAP3aBq3j7XetrQhadEaQYtADTiDCFmS2d2kjW6jMmMB+ZoCajxRyzVAohQSsIvaJ+UNMC3JdqYpzK/ZPYY9VawOQ3PpkuYsZu+yOTDiD2rFovaU+sV0mXnUrxCtYHq4rINHeCWaUUhm9LtnlhAt/cXdZdXr2p/E0Ppc9xAZcBZ2XwQ7eoYODbxPjE+CBuldOSxjaLtXEv27KyCHnAAZHaPajXORud20msMLu3cYkSwNy8I6x9qAkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ygZ9Xi66lq23OVEnQ0EqqatcYip0+q8EL73o6dD9UNw=; b=nf1GVRdht4nM9GqiXoAc3Ma8TQ2JTNfpwyKnC2fo7+KMlWJF5dQCFkE7R2mKAbOad93rs8NNAOakVOME/vuuxJaZS91bKONaxTgQFZTSAGrTGu6GbE0u3FMiiEU74bHAa6Na+JLkjBC6AGJGsbhKRktE3/0ojU9A7lhxhxj/0XU= Authentication-Results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5015.namprd11.prod.outlook.com (2603:10b6:510:39::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Thu, 2 Sep 2021 10:49:38 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4478.020; Thu, 2 Sep 2021 10:49:38 +0000 To: Tudor Cornea CC: , , , "Stephen Hemminger" , Andrew Rybchenko , Thomas Monjalon , "jerinj@marvell.com" References: <1629463607-76292-1-git-send-email-tudor.cornea@gmail.com> <1483bf7f-09ec-edd5-1fc1-4b4c81206ae2@intel.com> <20210901143420.5977fd9d@hermes.local> From: Ferruh Yigit X-User: ferruhy Message-ID: <182a292a-c004-d49b-fc3d-c48dba79206f@intel.com> Date: Thu, 2 Sep 2021 11:49:31 +0100 In-Reply-To: <20210901143420.5977fd9d@hermes.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DU2P251CA0017.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:230::16) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DU2P251CA0017.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:230::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Thu, 2 Sep 2021 10:49:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 94b4d7b7-7dc6-4a40-d2f8-08d96dff5c12 X-MS-TrafficTypeDiagnostic: PH0PR11MB5015: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Pdkz3h0sVFdGPbIiatMznUcHMGDpDEfcU3quaAOcnHae+QsrPEccRgM7jG+/q/3HDJ91UEu++Mxg/i8ppLnbyt3RAPmCyLpeghFcvYPDSp5925zBNxhylOhZCiO9+2zug45lO6Dmg4YlocmNgaTi8JPFo4Y9l+gNOTTikBqRyk9jHs2JPYW6egWfTQqaYV1j/OTwqbJNgAk2TT1hD9qbuVLSxp1RmUrTOMXHTfN90NeMz5BlU2MbEm+/7t95lLu7bQGNoz0AbhxSBWbRtb4/prKVsdmJPR5U/+xbjKuJMAx9AqmbV64A1McJPh0mOfw3XahQyRwi2DzQfwcjxpWRqzU7Gu7284PgMcMVLpuz+dGTqhzg6rTNLLcEGN9yCreDLn1r37ghuMGU3PQ6G8czU7YgeNqvTULiI8qcEnjXxCJe5I66t3P5zmNl34XPdFh0fncG85ABsNyaztK3TdR4RhDF+yG0znmy8ZbYVVDKi1eIyLx6OszY+MFTvPDoeqbh4UstNEafwrxkLhbpKdhi4Rq2ALuNy2VR6v/BH0gaR5dzUorTeJF4xc2sruoB9LfQxqGNi9xwvegG0AVV+eqmCTo2lpeu4TrN5cfeYd1OeNWUx5vAaKDu7t1yX+MookuSOegtmonCXzfrCiLO/LrkEDmqTr9EsBrldsF/WwgKSJTrAgztdif6cLdvBbkz7q+pC7thLhA0z15Fv2yh5PRIZ8fp8Zeta8lHCy1vGwJQmFz16EX5+EqXeIL+2yPoxj1aOQsCgqdIbHF5DzESqdp8t+mwTtyhZ2p1Mk1ksj/AgWU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(39860400002)(346002)(366004)(6666004)(956004)(6486002)(478600001)(6916009)(36756003)(8936002)(8676002)(86362001)(83380400001)(2906002)(4326008)(966005)(186003)(66476007)(16576012)(44832011)(316002)(38100700002)(31696002)(54906003)(31686004)(66946007)(26005)(2616005)(5660300002)(66556008)(53546011)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K0VBUmJjdkxHdDhkZU1qOEtSL0lSUmx3Y1FOYThyejVjYnpRR29GMEtZTmNE?= =?utf-8?B?VStINElZZGtrVzdmNDBjVGlKUG84YjdZTk5lc1ZmVytSWFNuclMrMXE1bUcr?= =?utf-8?B?UC9sYVM0M3k0SGV6dFR6L2lKZzlQemlrVFR5VzFiL284TmhOTHBRSVdrZmlV?= =?utf-8?B?UmYyajhVKzRZTWkvOW1nU090QU04UjJKSFJrQnd0a0lHNStYZnlpRmZ6MGtQ?= =?utf-8?B?TzN4bVZCM2kvanBmUS9aazVvd1NPNnpBWkYrRFl5SGhYUDFTUEtBRXpSYnNE?= =?utf-8?B?ekUwcFptdmwxYmUwVGpQblZvQms0TWtsVkdMMEVxK3JvTGFNcWZhRXE4SUNa?= =?utf-8?B?SVMxbDlkVC9WMUd6WTNvSk9HN25wYUFwZmtwa1FLS1RSclRtK2tJd2g4WTVw?= =?utf-8?B?MG1mTEV6cVV1Y0kxeWhpcTdmelJqYnNZU292YWhUWFJqbThZVE5SQVpmVXdZ?= =?utf-8?B?ZVBjSzFidWVxdzdvMkVMeVNtbU80VU8xRG9KRGducGtQdk5EMUtZTXVzNVp6?= =?utf-8?B?TkpmWVVtU0p0Z21EKzk2OUJwV09YMHc4N3BTVXovbFNpVGozSWxnT1N1OGdj?= =?utf-8?B?MGE1YmU2c3N1enBKWEltL1FCaFJNUEdFYkhpeElkQUM0UVczRGxldGdKd05W?= =?utf-8?B?WHcwbGpDcWE1dGx6Y1FWT0dFeHRZZEhjdXFSM2pTTVFtQXlyc05OUGtLbWFV?= =?utf-8?B?VWQ3WEJhdlM2bDVqYXN3aDJLaXJ1ZGF5b3ZBbUZDYjVNR1VsZmlIaXMrTjly?= =?utf-8?B?b09JYnExM1BXMFl3U2hIRXFoOEdaL25ldXpVbmcybDQvWFBVelM1cDU5UWpl?= =?utf-8?B?dmNoNytiS1BwMDBERnVYcEFCcWVBMGEycHFUcFlYOGxuTmFiai9DeHhUM3dZ?= =?utf-8?B?bGtvbEViMVFOaHRFd2VlYmdJUEc3N3UzZitIZ0VDR3J1eTR5VWxrY2dlc0dS?= =?utf-8?B?RzhIaTkzTHgvMXJFYW5xRUJpSFExRjd1bnFIRmtEbjlEajR0NXA0L1paNzFR?= =?utf-8?B?RVpURmZyTFVLalZnRnZTYWd1OVlGNzNoTEtQM1FMNmljUzZDSGRhNEZoQm5K?= =?utf-8?B?aDJzcVdlVmNvbHlCQnkxbmhMdjYrMVd3S3hvQ1NiRWRBNkhqZ2tBTTVmNm5N?= =?utf-8?B?aTVzYTNIVnhzV3lUaTA5YkViRUI2WXQ3VHNzSFVMSGR0VTI2TVFCOUQ2cE9z?= =?utf-8?B?c2NKQkVTOW40TzZxVmorekF5QS82ZGlDeW1OcysxeWRDR1FhdzVNN3hCQmVh?= =?utf-8?B?WWh2dXMyeDAwbEVyTXQwa2xma2ZkVmgxMzBvTGdLbmNuT3JYZ01NNkJ4bmVi?= =?utf-8?B?TGN2Z0orVWdmNE83VmZMYUZodDRGV0RtcnlHeEJLOTMrWmQ2Qlo5b0trRHo0?= =?utf-8?B?L2lZZlBDTlQ5clRWVDFXZHNCTjFPeWdRVzMvNXQ4NUttRFB5RndXUysyeHlu?= =?utf-8?B?QTRlMG9RSkpsbVgzdkhrQXplVlcxblVBTW5nNldqbDVvSk9QMVh5Y0hrUm1H?= =?utf-8?B?YVF6ZHVHYnlhdDcrclk2VEFYNWJKTU1QdGM1TWJ5cTh5cHExTjF6WnZwSElj?= =?utf-8?B?SzRFZnpFZUhidjRmcWcxNHlPWGswOTB3YkxnNHh4dGVlVE1IQXVxQTNrRnI3?= =?utf-8?B?c3hQN0l3R1VTcVRRUkkwQmdTUUFVVzU0blIwTHpkNVVhT25tckJodkwvYTZR?= =?utf-8?B?ZGptSDI0dTVkQ2twYmIxLzgxM1lvbTZBdnFRTWxwbndJVDBmeDJzN0pSdjh4?= =?utf-8?Q?jjuRE+LOfIs7/wg0lqNq8E7829RF2BZgedti64b?= X-MS-Exchange-CrossTenant-Network-Message-Id: 94b4d7b7-7dc6-4a40-d2f8-08d96dff5c12 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2021 10:49:38.0303 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uAhUOM//DEruUYfT7vtBQCNdgkHJJ7nzDGN/OUep64KU10ujcCmiFUrjKkzrCaQ0LZ1q3DNvVyxR0tvoWfDpgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5015 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] net/af_packet: try to reinsert the stripped vlan tag X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/1/2021 10:34 PM, Stephen Hemminger wrote: > On Wed, 1 Sep 2021 22:07:22 +0300 > Tudor Cornea wrote: > >> Indeed, the vlan insertion could be a costly operation. We should probably >> do it only if the user specifically asks to have the vlan tag in the packet. >> Otherwise, af_packet PMD users might pay a price in terms of performance >> for something they didn't ask for. >> >> I was thinking of avoiding having to change the application in order to >> re-insert the vlan tag. >> Doing this operation inside the PMD driver seemed like a good fit. >> >> Looking at the netvsc driver (drivers/net/netvsc), the vlan insertion is >> guarded by a check to hv->vlan_strip >> >> if (!hv->vlan_strip && rte_vlan_insert(&m)) { >> >> hv->vlan_strip seems to be initialized in hn_dev_configure() in the >> following way >> >> hv->vlan_strip = !!(rxmode->offloads & DEV_RX_OFFLOAD_VLAN_STRIP); >> >> while 'hv' seems to be stored in rte_eth_dev->data->dev_private >> >> I am thinking of doing something similar for the af_packet PMD. >> The 'pmd_internals' structure could potentially hold a field, say >> vlan_strip', which could be initialized if the application enables the >> DEV_RX_OFFLOAD_VLAN_STRIP in rxmode->offloads >> >> This way, I'm thinking that the application could potentially control the >> effect of vlan stripping for the af_packet PMD, in an uniform way, similar >> to other PMDs. >> Would this be considered an acceptable solution ? >> >> >> >> >> On Tue, 31 Aug 2021 at 18:31, Ferruh Yigit wrote: >> >>> On 8/20/2021 1:46 PM, Tudor Cornea wrote: >>>> The af_packet pmd driver binds to a raw socket and allows >>>> sending and receiving of packets through the kernel. >>>> >>>> Since commit bcc6d47903 [1], the kernel strips the vlan tags early in >>>> __netif_receive_skb_core(), so we receive untagged packets while >>>> running with the af_packet pmd. >>>> >>>> Luckily for us, the skb vlan-related fields are still populated from the >>>> stripped vlan tags, so we end up having all the information >>>> that we need in the mbuf. >>>> >>>> We would like to have the the vlan tag inside the mbuf. >>>> Let's take a shot at it by trying to reinsert the stripped vlan tag. >>>> >>> >>> PMD already sets 'mbuf->vlan_tci' and 'PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED' >>> flags, so application can be aware of the vlan tag and can consume it. >>> >>> Inserting the vlan tag back to packet is costly, what is the motivation to >>> do so? >>> >>>> As a side note, something similar was done for the netvsc pmd. >>>> >>>> [1] >>> https://github.com/torvalds/linux/commit/bcc6d47903612c3861201cc3a866fb604f26b8b2 >>>> >>>> Signed-off-by: Tudor Cornea > > The netvsc PMD has to handle some subtle cases where VLAN stripping > is done by the VF but the slow path over vmbus does not. > Since most traffic goes over the VF path, it makes sense for the > netvsc PMD to advertise and handle VLAN stripping even if it has > to do it in software. > > Ferruh is right the mbuf generated by current AF_PACKET PMD is > valid with VLAN stripped correctly. I think you are also correct > that the stripping needs to be controllable by the application. > And yes the kernel always strips the VLAN; there is no option > to tell socket(AF_PACKET) not to do that. > When application doesn't set VLAN_STRIP offload, expectation is VLAN tag to be in the packet and no additional work is done. But that is not the case for af_packet. If your change is applied, not requesting any offload, default confing, may cause unintended work for af_packet, since it will insert the already stripped vlan tag back. And we don't have a way to say any specific offload can't be disabled by the PMD/device, although we hit this case a few times previously. Proper fix can be adding this support to offloads, but it is more invasive change. + Andrew, Thomas, Jerin for this discussion. For short term at least 'DEV_RX_OFFLOAD_VLAN_STRIP' offload should be added to the af_packet capability. It is also possible to set this offload in the config by PMD itself even application doesn't request it, to be correct in the config. Not sure how much it helps to applications (there is a new API proposed this release to get config to application, perhaps after configuration step app can request the config and recognize that VLAN_STRIP offload is set by PMD, but this is some overhead).