From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <3chas3@gmail.com> Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by dpdk.org (Postfix) with ESMTP id 3D3121B45B; Tue, 26 Mar 2019 19:02:02 +0100 (CET) Received: by mail-qt1-f194.google.com with SMTP id v20so15645104qtv.12; Tue, 26 Mar 2019 11:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yMeoXnjMeOhb1TJIxMB97BIdiLyUWButQLV4xzRZx+E=; b=h7b7c/w0jbhjvYldLrJmmqCOzgoDJ/KYs54RKgrY0EUEaGhToT3mSkxpsY5CXEpRWv rtwKzYzbURqWdZT/J8bzliNwBAK3AyL/GG3hbNI20REkjtc8ahZ7xp2q6gcSNKxtx0u6 IdBT/1AjB6oQ64Ceb5U32znYugQ6Y7RSGl8lB8MgGyJ1woIo/sqKtrHPz97GHGgF4sfk uqs4Pmna5vNZQhJ1EtGI7bwmfbkNhvf0PkaZXvH2r9J06gDxDkMPtJnpAdVRadAO4WAl cTlz6RFYqzwlG8TIE2IR/LGZF06FjyXoNXoZ9EBwGeLPHhR9GxnLYY/sIe+Im6e6+TCG VOWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yMeoXnjMeOhb1TJIxMB97BIdiLyUWButQLV4xzRZx+E=; b=CJI9O5CNFNc8vGpmFOLPoq06DOTPCGDVWo6HCYdeeKRsedazr1t0TwV6GXLQjOm6O1 pzUvmbeKKpgZrZJWDnrrOoeW9K8SlXN1/8F1oqCvQHfk0YJ/Dd5JrX42YWqIld9tZOIU DIOJgGznr/q8DrRBDOZhPH6bY+LkRS4J8p52tZAUPdbF4AtG3NzQ3Ypx7+p+SOPLHLCO 5pi3SPYxNNKJulj9nqIH7bFIUV3ZIlwI9Ec32u7iWGTMkWjIGvrB6F4SdVN3McURw/Rc 7ff1QqmNHWVwiaK0ZKuR6PSekS5Szi22lHXYrMI2TwmN45HQy1qK06WHRdUcZSB6FaLu NoVw== X-Gm-Message-State: APjAAAWUNPTPigxxeLgaxTgcCB7+A7G47dxDpKRRFdbaDyxV1AcBlFrC Q5oq8XzWyZta1IO9Ug2x32s= X-Google-Smtp-Source: APXvYqwP46z3SPZGtka4Zg1YyBL820gvdM3XIfDb0g9g3v5JJ9xosbSX3TfY012Pfsi3W3OUiSpvsw== X-Received: by 2002:a0c:afce:: with SMTP id t14mr26832911qvc.147.1553623321621; Tue, 26 Mar 2019 11:02:01 -0700 (PDT) Received: from [192.168.1.10] (pool-96-255-82-34.washdc.fios.verizon.net. [96.255.82.34]) by smtp.gmail.com with ESMTPSA id c50sm1055700qtd.60.2019.03.26.11.01.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 11:01:59 -0700 (PDT) To: Ferruh Yigit , dev@dpdk.org, olivier.matz@6wind.com Cc: stable@dpdk.org, Chas Williams , Andrew Rybchenko References: <20190325150541.12087-1-3chas3@gmail.com> <23cc0c89-0333-3300-6acb-e69d8d56c811@intel.com> From: Chas Williams <3chas3@gmail.com> Message-ID: <9b0d3a56-4941-dfb4-5702-fb09e913cf96@gmail.com> Date: Tue, 26 Mar 2019 14:01:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <23cc0c89-0333-3300-6acb-e69d8d56c811@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net: fix Tx VLAN flag for offload emulation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 18:02:02 -0000 On 3/26/19 12:50 PM, Ferruh Yigit wrote: > On 3/25/2019 3:05 PM, Chas Williams wrote: >> From: Bill Hong >> >> A PMD might use rte_vlan_insert to implement Tx VLAN offload. Typically >> the PMD will insert the VLAN header in the transmit path and then attempt >> to send the packets. If this fails, the packets are returned to >> the application which may attempt to send these packets again. If the >> PKT_TX_VLAN flag is not cleared, the transmit path may attempt to insert >> the VLAN header again. >> >> Fixes: 47aa48b969f8 ("net: fix stripped VLAN flag for offload emulation"); >> Cc: stable@dpdk.org >> >> Signed-off-by: Bill Hong >> Signed-off-by: Chas Williams >> --- >> lib/librte_net/rte_ether.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h >> index c2c5e249f..e0d831113 100644 >> --- a/lib/librte_net/rte_ether.h >> +++ b/lib/librte_net/rte_ether.h >> @@ -408,7 +408,7 @@ static inline int rte_vlan_insert(struct rte_mbuf **m) >> vh = (struct vlan_hdr *) (nh + 1); >> vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci); >> >> - (*m)->ol_flags &= ~PKT_RX_VLAN_STRIPPED; >> + (*m)->ol_flags &= ~(PKT_RX_VLAN_STRIPPED | PKT_TX_VLAN); > > Hi Chas, > > Looks reasonable, AFAIK, PKT_TX_VLAN flag means 'mbuf->vlan_tci' has valid value > and a request from application to driver to insert VLAN information. > After successful insertion flag can be removed. > > But in mbuf header, flags documented as: > PKT_TX_VLAN: TX packet is a 802.1q VLAN packet. > PKT_TX_QINQ: TX packet with double VLAN inserted. Note the usage slightly below: /** * Bitmask of all supported packet Tx offload features flags, * which can be set for packet. */ #define PKT_TX_OFFLOAD_MASK ( \ PKT_TX_OUTER_IPV6 | \ PKT_TX_OUTER_IPV4 | \ PKT_TX_OUTER_IP_CKSUM | \ PKT_TX_VLAN_PKT | \ So this implies that PKT_TX_VLAN_PKT (which is PKT_TX_VLAN's old name) is an offload feature, not that the actual packet has an 802.1q header (offloaded or otherwise). The same seems to apply for PKT_TX_QINQ. > Hi Oliver, > > Is above comments correct, or I am missing something J > > > Also here cleaning 'PKT_RX_VLAN_STRIPPED' looks like to say 'vlan' information > is not stripped but in the packet data, but 'RX' in this context can be > confusing, should we have a more generic 'PKT_VLAN_STRIPPED' ? > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 18FC7A05D3 for ; Tue, 26 Mar 2019 19:02:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4448E1B45F; Tue, 26 Mar 2019 19:02:03 +0100 (CET) Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by dpdk.org (Postfix) with ESMTP id 3D3121B45B; Tue, 26 Mar 2019 19:02:02 +0100 (CET) Received: by mail-qt1-f194.google.com with SMTP id v20so15645104qtv.12; Tue, 26 Mar 2019 11:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yMeoXnjMeOhb1TJIxMB97BIdiLyUWButQLV4xzRZx+E=; b=h7b7c/w0jbhjvYldLrJmmqCOzgoDJ/KYs54RKgrY0EUEaGhToT3mSkxpsY5CXEpRWv rtwKzYzbURqWdZT/J8bzliNwBAK3AyL/GG3hbNI20REkjtc8ahZ7xp2q6gcSNKxtx0u6 IdBT/1AjB6oQ64Ceb5U32znYugQ6Y7RSGl8lB8MgGyJ1woIo/sqKtrHPz97GHGgF4sfk uqs4Pmna5vNZQhJ1EtGI7bwmfbkNhvf0PkaZXvH2r9J06gDxDkMPtJnpAdVRadAO4WAl cTlz6RFYqzwlG8TIE2IR/LGZF06FjyXoNXoZ9EBwGeLPHhR9GxnLYY/sIe+Im6e6+TCG VOWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yMeoXnjMeOhb1TJIxMB97BIdiLyUWButQLV4xzRZx+E=; b=CJI9O5CNFNc8vGpmFOLPoq06DOTPCGDVWo6HCYdeeKRsedazr1t0TwV6GXLQjOm6O1 pzUvmbeKKpgZrZJWDnrrOoeW9K8SlXN1/8F1oqCvQHfk0YJ/Dd5JrX42YWqIld9tZOIU DIOJgGznr/q8DrRBDOZhPH6bY+LkRS4J8p52tZAUPdbF4AtG3NzQ3Ypx7+p+SOPLHLCO 5pi3SPYxNNKJulj9nqIH7bFIUV3ZIlwI9Ec32u7iWGTMkWjIGvrB6F4SdVN3McURw/Rc 7ff1QqmNHWVwiaK0ZKuR6PSekS5Szi22lHXYrMI2TwmN45HQy1qK06WHRdUcZSB6FaLu NoVw== X-Gm-Message-State: APjAAAWUNPTPigxxeLgaxTgcCB7+A7G47dxDpKRRFdbaDyxV1AcBlFrC Q5oq8XzWyZta1IO9Ug2x32s= X-Google-Smtp-Source: APXvYqwP46z3SPZGtka4Zg1YyBL820gvdM3XIfDb0g9g3v5JJ9xosbSX3TfY012Pfsi3W3OUiSpvsw== X-Received: by 2002:a0c:afce:: with SMTP id t14mr26832911qvc.147.1553623321621; Tue, 26 Mar 2019 11:02:01 -0700 (PDT) Received: from [192.168.1.10] (pool-96-255-82-34.washdc.fios.verizon.net. [96.255.82.34]) by smtp.gmail.com with ESMTPSA id c50sm1055700qtd.60.2019.03.26.11.01.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 11:01:59 -0700 (PDT) To: Ferruh Yigit , dev@dpdk.org, olivier.matz@6wind.com Cc: stable@dpdk.org, Chas Williams , Andrew Rybchenko References: <20190325150541.12087-1-3chas3@gmail.com> <23cc0c89-0333-3300-6acb-e69d8d56c811@intel.com> From: Chas Williams <3chas3@gmail.com> Message-ID: <9b0d3a56-4941-dfb4-5702-fb09e913cf96@gmail.com> Date: Tue, 26 Mar 2019 14:01:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <23cc0c89-0333-3300-6acb-e69d8d56c811@intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] net: fix Tx VLAN flag for offload emulation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Message-ID: <20190326180159.ijS2zS7r83Yib0utMfzWU7cZoTE5MAnFqk0gkulZlNg@z> On 3/26/19 12:50 PM, Ferruh Yigit wrote: > On 3/25/2019 3:05 PM, Chas Williams wrote: >> From: Bill Hong >> >> A PMD might use rte_vlan_insert to implement Tx VLAN offload. Typically >> the PMD will insert the VLAN header in the transmit path and then attempt >> to send the packets. If this fails, the packets are returned to >> the application which may attempt to send these packets again. If the >> PKT_TX_VLAN flag is not cleared, the transmit path may attempt to insert >> the VLAN header again. >> >> Fixes: 47aa48b969f8 ("net: fix stripped VLAN flag for offload emulation"); >> Cc: stable@dpdk.org >> >> Signed-off-by: Bill Hong >> Signed-off-by: Chas Williams >> --- >> lib/librte_net/rte_ether.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h >> index c2c5e249f..e0d831113 100644 >> --- a/lib/librte_net/rte_ether.h >> +++ b/lib/librte_net/rte_ether.h >> @@ -408,7 +408,7 @@ static inline int rte_vlan_insert(struct rte_mbuf **m) >> vh = (struct vlan_hdr *) (nh + 1); >> vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci); >> >> - (*m)->ol_flags &= ~PKT_RX_VLAN_STRIPPED; >> + (*m)->ol_flags &= ~(PKT_RX_VLAN_STRIPPED | PKT_TX_VLAN); > > Hi Chas, > > Looks reasonable, AFAIK, PKT_TX_VLAN flag means 'mbuf->vlan_tci' has valid value > and a request from application to driver to insert VLAN information. > After successful insertion flag can be removed. > > But in mbuf header, flags documented as: > PKT_TX_VLAN: TX packet is a 802.1q VLAN packet. > PKT_TX_QINQ: TX packet with double VLAN inserted. Note the usage slightly below: /** * Bitmask of all supported packet Tx offload features flags, * which can be set for packet. */ #define PKT_TX_OFFLOAD_MASK ( \ PKT_TX_OUTER_IPV6 | \ PKT_TX_OUTER_IPV4 | \ PKT_TX_OUTER_IP_CKSUM | \ PKT_TX_VLAN_PKT | \ So this implies that PKT_TX_VLAN_PKT (which is PKT_TX_VLAN's old name) is an offload feature, not that the actual packet has an 802.1q header (offloaded or otherwise). The same seems to apply for PKT_TX_QINQ. > Hi Oliver, > > Is above comments correct, or I am missing something J > > > Also here cleaning 'PKT_RX_VLAN_STRIPPED' looks like to say 'vlan' information > is not stripped but in the packet data, but 'RX' in this context can be > confusing, should we have a more generic 'PKT_VLAN_STRIPPED' ? >