From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com
[209.85.192.180]) by dpdk.org (Postfix) with ESMTP id 42399FFA
for <dev@dpdk.org>; Thu, 7 Apr 2016 19:35:10 +0200 (CEST)
Received: by mail-pf0-f180.google.com with SMTP id c20so59679334pfc.1
for <dev@dpdk.org>; Thu, 07 Apr 2016 10:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=r1Wq/Df1h86gckARXA9dy4S68VI0mEOXXalFoQDMT6k=;
b=bTTy19rMFYzDStQBHMnsCMc4sRRxxn44Ad1dz7/E41K2l1YsDgDldvfGBlPwEE5VmQ
qbOZ3CxAxgcZnFuEZGS1139CYtkOZwZFBoXZnLvjLXI/tQs02rDq+vrDO97UPDNy42ax
uz9BQQmfZTFbS15RT535ifiHCYI2ukTExPgUMzqt0q0uBJeAhxxSUWWil5VpSea2to3g
oMiI7cio/ZSEiEAxcEmPk9uRzWH8m7akvyxc4sKhdVOJZGLgG1gbXxZdRvDxO9ARtzVD
Lqs5U4Yjv496es6cHQUKjKrReYCG2HYboY0ztYmsxe06VererWa08z8iRS01AIW6pwXG
uHFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=r1Wq/Df1h86gckARXA9dy4S68VI0mEOXXalFoQDMT6k=;
b=UdYNaoI2F0EE9drSdRaTn+kV5+JSQWVH/cVSClnHwzdwB+h5pODT+fDTFNy9bgHw8w
1y+rhKXoyfHsFsViTIN5Vc1+5pAlI3aiyl0+BiDJbZ3eqexuyxekSfYqwIUSTh3pX0Q1
Jphl+LPo7gRV8mZs89vh2AVht7VxdkkZqv8a+HAMeTk72jE84LgqPvcZ+wg2oZtNpoRj
XjWOnGtkHNUkSIeQRGYd95FYrp4XJDhyQ207Cp3l8BqcWEFo1i67kjjYWpsIA9IzM4zy
OqS5Uuw9F5LAid9ydN3lcBRZ2lOntpVPqy5m2Jwrk9wDos+fEdj8PoF0OF3qNN3CDX9e
L33g==
X-Gm-Message-State: AD7BkJJvpAE9QVKNNUdwLGUUI5vk0EQCVxuzWkfymn41dqRtvdbA/kN6o/YiY1LynI6c/w==
X-Received: by 10.98.32.23 with SMTP id g23mr6275503pfg.74.1460050509589;
Thu, 07 Apr 2016 10:35:09 -0700 (PDT)
Received: from xeon-e3 (static-50-53-71-109.bvtn.or.frontiernet.net.
[50.53.71.109])
by smtp.gmail.com with ESMTPSA id u2sm13566230pfi.26.2016.04.07.10.35.09
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 07 Apr 2016 10:35:09 -0700 (PDT)
Date: Thu, 7 Apr 2016 10:35:22 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: John Guzik <john@shieldxnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Message-ID: <20160407103522.2d3d7953@xeon-e3>
In-Reply-To: <SN1PR20MB028564DE6A82A22983157757DC900@SN1PR20MB0285.namprd20.prod.outlook.com>
References: <SN1PR20MB028564DE6A82A22983157757DC900@SN1PR20MB0285.namprd20.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] vmxnet3 driver - vlan offload is on end descriptor
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2016 17:35:10 -0000
On Thu, 7 Apr 2016 17:11:19 +0000
John Guzik <john@shieldxnetworks.com> wrote:
> With the new jumbo frame patch a latent bug has appeared to have been uncovered: the VLAN offload is on the last rx descriptor, when rcd->eop is true, not the first rx descriptor, when rcd->sop is true and rcd->eop could be false.
> Most likely the reason this has not been seen before is that for non-jumbo frames rcd->eop has always been true when rcd->sop is true as well.
>
> The following patch should fix the problem:
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> index 4ac0456..3d4a5eb 100644
> --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
> +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
> @@ -587,12 +587,6 @@ vmxnet3_post_rx_bufs(vmxnet3_rx_queue_t *rxq, uint8_t ring_id)
> static void
> vmxnet3_rx_offload(const Vmxnet3_RxCompDesc *rcd, struct rte_mbuf *rxm)
> {
> - /* Check for hardware stripped VLAN tag */
> - if (rcd->ts) {
> - rxm->ol_flags |= PKT_RX_VLAN_PKT;
> - rxm->vlan_tci = rte_le_to_cpu_16((uint16_t)rcd->tci);
> - }
> -
> /* Check for RSS */
> if (rcd->rssType != VMXNET3_RCD_RSS_TYPE_NONE) {
> rxm->ol_flags |= PKT_RX_RSS_HASH;
> @@ -737,7 +731,15 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
> rxq->last_seg = rxm;
>
> if (rcd->eop) {
> - rx_pkts[nb_rx++] = rxq->start_seg;
> + struct rte_mbuf *start = rxq->start_seg;
> +
> + /* Check for hardware stripped VLAN tag */
> + if (rcd->ts) {
> + start->ol_flags |= PKT_RX_VLAN_PKT;
> + start->vlan_tci = rte_le_to_cpu_16((uint16_t)rcd->tci);
> + }
> +
> + rx_pkts[nb_rx++] = start;
> rxq->start_seg = NULL;
> }
>
>
Yes, your analysis and bug fix looks correct. The Linux driver checks for VLAN tag in the
last (eop) segment.
Acked-by: Stephen Hemminger <stephen@networkplumber.org>