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 DFE9342C5E; Thu, 8 Jun 2023 14:37:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 64DF2406B5; Thu, 8 Jun 2023 14:37:28 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 9154940042 for ; Thu, 8 Jun 2023 14:37:26 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 6161259; Thu, 8 Jun 2023 15:37:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 6161259 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1686227845; bh=HOy0OSVbygGHaokVV6xA5FCs1AayjJKEeHqUXgnacVc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BiJKb045b5BjmeZwaD+wpQj9PX8/z+l1trwoBKeMC6Q0OE+O8DuHxfiRHkb77JUP3 olA34LPyC1hAudSwEdTRt+WRkn+2n3mF7MDnHNX7ue/DZ/2wwVrqH0o6zglFviTX4b KZVuBkXPqrxR1K6httOUi0Es58Wxcsg3vGlFvqgI= Message-ID: Date: Thu, 8 Jun 2023 15:37:24 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v4 2/3] common/sfc_efx/base: add support to enable VLAN stripping Content-Language: en-US To: Artemii Morozov , dev@dpdk.org Cc: Ivan Malov , Viacheslav Galaktionov , Andy Moreton References: <20230531134122.119508-1-artemii.morozov@arknetworks.am> <20230601153022.99634-1-artemii.morozov@arknetworks.am> <20230601153022.99634-3-artemii.morozov@arknetworks.am> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 On 6/8/23 14:16, Artemii Morozov wrote: > Hello, > > On 6/2/23 12:32, Andrew Rybchenko wrote: >> On 6/1/23 18:30, Artemii Morozov wrote: >>> To enable VLAN stripping, two conditions must be met: >>> the corresponding flag must be set and the appropriate >>> RX prefix should be requested. >> >> RX -> Rx >> >>> VLAN stripping is supported for ef100 datapath only. >> >> When you read below notes carefully, you'll understand that the >> patch is very raw yet. There are too many questions below. >> >> The major decision to be made is if libefx API should enforce >> device level offload or should just provide transparent API and >> driver must be responsible for consistency. >> >> If driver must be responsible for consistency, don't try to >> enforce VLAN stripping enable via filter table. RxQ flags >> should control stripped VLAN delivery. Filter flag and default >> RxQ set flag (API should be extended) should control VLAN >> stripping enabling. >> >> If libefx must guarantee consistency, we need a new way to >> enable device level offload early (efx_rx_init()-like, may >> be a new API). If so, it should be impossible to control >> VLAN stripping per Rx filter. It still could be possible >> to control stripped VLAN delivery per RxQ. >> >> Anyway current solution is really inconsistent. > > How about the following concept: > > 1. Add a new negotiated flag for metadata: RTE_ETH_RX_METADATA_VLAN_INFO. > > 2. Extend the driver to allow requesting the delivery of stripped VLAN > TCI through the metadata >     negotiation method. This request will internally affect the Rx > prefix configuration via >     libefx EFX_RXQ_FLAG_VLAN_TCI (or something like that). > > 3.  Set the corresponding boolean flag in the sfc_port(strip_vlan = > something like that please advice) >      structure if RTE_ETH_RX_OFFLOAD_VLAN_STRIP is received. Map this > flag to the corresponding flag in >      efx_nic_t, Then, when generating specs for filters, use the > boolean flag from efx_nic_t to determine >      the VLAN stripping behavior. > > 4. Users can request VLAN strip action. If a user does not request this > action, but the driver detects that >    device-level stripping has been requested, it may implicitly enable > VLAN stripping for that specific flow >    within the efx_mcdi_filter_op_add function. > > In this concept, we allow the enabling of device-level VLAN stripping. > Points 1 and 2 concern the delivery of stripped VLAN TCI, while points 3 > and 4 pertain to the request for VLAN tag stripping. > It does not reply my questions and I see no single point to complicate VLAN stripping configuration and introduce corresponding Rx metadata control. Device-level offload is sufficient and configured early enough to do its job.