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 69965A00C2; Mon, 31 Oct 2022 22:56:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 46AD040685; Mon, 31 Oct 2022 22:56:56 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 4B48140223 for ; Mon, 31 Oct 2022 22:56:54 +0100 (CET) Received: by shelob.oktetlabs.ru (Postfix, from userid 115) id B28A362; Tue, 1 Nov 2022 00:56:53 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mail1.oktetlabs.ru X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_DISCARD, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 Received: from bree.oktetlabs.ru (bree.oktetlabs.ru [192.168.34.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPS id 0D9155A; Tue, 1 Nov 2022 00:56:53 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 0D9155A Authentication-Results: shelob.oktetlabs.ru/0D9155A; dkim=none; dkim-atps=neutral Date: Tue, 1 Nov 2022 00:56:52 +0300 (MSK) From: Ivan Malov To: Ferruh Yigit cc: dev@dpdk.org, Qi Z Zhang , Qiming Yang , Wenjun Wu , Thomas Monjalon , John McNamara , Andrew Rybchenko , Jerin Jacob Kollanukkaran Subject: Re: Understanding RX_OFFLOAD_VLAN_EXTEND In-Reply-To: <97a009d2-87cf-c901-590d-7c4dad37d6ca@amd.com> Message-ID: References: <911e37b-7c27-5bbb-ca40-4b778d396fff@oktetlabs.ru> <97a009d2-87cf-c901-590d-7c4dad37d6ca@amd.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463810782-53748080-1667253413=:1599708" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463810782-53748080-1667253413=:1599708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Thank you, Ferruh. You have been most helpful. On Mon, 31 Oct 2022, Ferruh Yigit wrote: > On 10/31/2022 6:46 PM, Ivan Malov wrote: >> Hi! >> >> We have a hard time figuring out what the API contract of >> RX_OFFLOAD_VLAN_EXTEND might be. The best educated guess >> we can make is that the feature might have something to >> do with identifying VLAN packets and extracting TCI >> without stripping the tags from incoming packets. >> >> Is this understanding correct? >> >> You see, things aren't helped by the offload bit having >> almost no commentary. Such could've shed light on its >> meaning. Perhaps this gap in documentation should >> be addressed somehow. Any opinions? >> >> Thank you. > > > Hi Ivan, > > It is legacy from ixgbe driver, you can find more details on the ixgbe > (82599) datasheet [1]. > > RX_OFFLOAD_VLAN_EXTEND is *like*, QinQ but not, that is why we have > 'QINQ_STRIP' offload. > > And RX_OFFLOAD_VLAN_EXTEND is more a configuration option, briefly you can > ignore it. > But in detail that is to configure device in a mode that it knows that > received packets always has at least one VLAN tag, I assume it is for a case > that some in the middle networking device inserts/requires VLAN tags. But > optionally packet can have two VLAN tags. But as far as I can see this is not > for to strip the VLAN tag or to filter packet based on it, this is just to > configure device for this environment. > > > > [1] copy/paste from a public datasheet > (http://iommu.com/datasheets/ixgbe-datasheets/82599-datasheet-v3-4.pdf), not > sure if this is up to date version, but I think it is OK for this context: > > Double VLAN and Single VLAN Support > The 82599 supports a mode where all received and sent packets have at least > one VLAN tag in addition to the regular tagging that might optionally be > added. In this document, when a packet carries two VLAN headers, the first > header is referred to as an outer VLAN and the second header as an inner VLAN > header (as listed in the table that follows). This mode is used for systems > where the near end switch adds the outer VLAN header containing switching > information. This mode is enabled by the following configuration: > • This mode is activated by setting the DMATXCTL.GDV and the Extended VLAN > bit in the CTRL_EXT register. > • The EtherType of the VLAN tag used for the additional VLAN is defined in > the VET EXT field in the EXVET register. > ---1463810782-53748080-1667253413=:1599708--