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 D565B42C5C; Thu, 8 Jun 2023 13:16:58 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 78C8F406B5; Thu, 8 Jun 2023 13:16:58 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id 826BB40042 for ; Thu, 8 Jun 2023 13:16:57 +0200 (CEST) Received: from [192.168.2.179] (unknown [141.136.91.149]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id DEEBAE04B8; Thu, 8 Jun 2023 15:16:56 +0400 (+04) Message-ID: Date: Thu, 8 Jun 2023 15:16:51 +0400 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 To: dev@dpdk.org Cc: Ivan Malov , Viacheslav Galaktionov , Andy Moreton , Andrew Rybchenko References: <20230531134122.119508-1-artemii.morozov@arknetworks.am> <20230601153022.99634-1-artemii.morozov@arknetworks.am> <20230601153022.99634-3-artemii.morozov@arknetworks.am> Content-Language: en-US From: Artemii Morozov 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 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.