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 7B246A00C2; Mon, 31 Oct 2022 19:46:23 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B28740685; Mon, 31 Oct 2022 19:46:23 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 43CC540223 for ; Mon, 31 Oct 2022 19:46:21 +0100 (CET) Received: by shelob.oktetlabs.ru (Postfix, from userid 115) id BE87766; Mon, 31 Oct 2022 21:46:20 +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 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 306A35A; Mon, 31 Oct 2022 21:46:20 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 306A35A Authentication-Results: shelob.oktetlabs.ru/306A35A; dkim=none; dkim-atps=neutral Date: Mon, 31 Oct 2022 21:46:20 +0300 (MSK) From: Ivan Malov To: dev@dpdk.org cc: Thomas Monjalon , John McNamara , Andrew Rybchenko Subject: Understanding RX_OFFLOAD_VLAN_EXTEND Message-ID: <911e37b-7c27-5bbb-ca40-4b778d396fff@oktetlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII 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 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.