From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <adrien.mazarguil@6wind.com>
Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65])
by dpdk.org (Postfix) with ESMTP id 430D81B6BE
for <dev@dpdk.org>; Fri, 10 Nov 2017 11:06:38 +0100 (CET)
Received: by mail-wm0-f65.google.com with SMTP id n74so5234644wmi.1
for <dev@dpdk.org>; Fri, 10 Nov 2017 02:06:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=6wind-com.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to;
bh=i7yZvyZDhfituw5+7niGzufPSywX99/0+78qtFZVCDk=;
b=qchmSQ0LV8r0/QrAZVXeArOXeABk1lUIxHoYbMRxImS+8Vcso6hB1j9pm9iw5Ih+L2
XwxEMLYW0oFfFg0K0Ayz4cbW8TRFc5YL3XrtWisrMiIlIkOtgbwtApk5q+0pnLKsp2z3
FxItTvg4RJlYWGj8txVzWHyLdE/KaNL6XD3lWXKY5z8hOtEKEJrOyLI6gyiKh5NHFhv5
OgmhUmrCa9ma3HRG6IYo5FSc53+w5WcvjRvZ8iHZgJTfX/6zv6lrlpJIZgUcgOH6m42v
Sh648IM0gKXylDDpr96I5oAOohkSi4INVYVkvoD0bedptjjNSb9vN8Qe+qNJ2HFMvxQ3
JUMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to;
bh=i7yZvyZDhfituw5+7niGzufPSywX99/0+78qtFZVCDk=;
b=QPi9+xj2HG/jqwPmkDnE4hxh0S4B+8xF6eLVCEgf9s8SY5iNFoLoCELY3fHiFuTA+T
j7cVx+FEcixxjWl5kC7QFe5F5fFTAQXEkVDG6ljk31xC0ZAM7AgU5SdFUz89KQ50mlHr
2jHdaFMbQgUQTO2rqxir5v5nai9YMsd9jfqSruvzEfM20To97CzcVutMQrPGcjQU7CyY
PPlzqqF41/8vdSjspqBJCJ87yDjXT83jgDgm7xUzZpxF52b/1D9+Yob8ly6AyBrPxkym
ih1nwwkXDNiyEmfklpHZBkQCHi/yoMxWsxfoHUKLYr301E+0Jto6jlF1TvjTtrVmJbuC
Zv8g==
X-Gm-Message-State: AJaThX4prVEo+rJ0n2FNiFT+kuAQTeW3/H7NdeRVKxr+2nsDCJmXwXNa
Gr/mHpASqMi6gpczFwWPdjyyww==
X-Google-Smtp-Source: ABhQp+T0hwUdvga4BVWjJNX2rwyFSCBSED4B3WkU5GykQ1nuyuO9X08O/kpTY/hYkAhf6SfQB1iDyA==
X-Received: by 10.80.152.16 with SMTP id g16mr1793284edb.28.1510308397892;
Fri, 10 Nov 2017 02:06:37 -0800 (PST)
Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78])
by smtp.gmail.com with ESMTPSA id f46sm7233938edd.80.2017.11.10.02.06.36
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 10 Nov 2017 02:06:36 -0800 (PST)
Date: Fri, 10 Nov 2017 11:06:25 +0100
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Ori Kam <orika@mellanox.com>
Cc: nelio.laranjeiro@6wind.com, yskoh@mellanox.com, dev@dpdk.org,
stable@dpdk.org
Message-ID: <20171110100625.GF24849@6wind.com>
References: <1510243472-24872-1-git-send-email-orika@mellanox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1510243472-24872-1-git-send-email-orika@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix number of segment calculation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <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: Fri, 10 Nov 2017 10:06:38 -0000
Hi Ori,
On Thu, Nov 09, 2017 at 06:04:32PM +0200, Ori Kam wrote:
> The CRC size should be taken into consideration when computing
> the number of mbuf segments for packet on the receive path.
> Large packets can be dropped due to extra CRC length.
>
> Fixes: a1366b1a2be3 ("net/mlx5: add reference counter on DPDK Rx queues")
> Cc: stable@dpdk.org
> Cc: nelio.laranjeiro@6wind.com
>
> Signed-off-by: Ori Kam <orika@mellanox.com>
I don't think there's an issue to fix, there's actually a reason it's done
that way, perhaps I'm wrong but let me elaborate.
When applications request CRC to be written to mbuf (more precisely not to
be stripped), its extra 4 bytes are neither part of mbuf->pkt_len nor
mbuf->data_len. It just happens to be written past mbuf data if there's room
for it, where applications knowingly expect it based on how they configured
the PMD. That's the API.
This implies applications also size mbufs accordingly; if they don't provide
room for the CRC, it can't be written. This extra room is assumed to be part
of max_rx_pkt_len. When CRC stripping is requested, they do not have to
provide such room (IBV_WQ_FLAGS_SCATTER_FCS is not set on mlx5 Rx queues).
One problem with your proposal is assuming all segments are consumed
entirely during Rx and max_rx_pkt_len is reached, another segment with zero
data length gets appended just to hold the CRC. Applications may interpret
this as a bug.
Another problem is this doesn't solve the issue when Rx scatter is disabled
although it's no different from when packet data consumes all segments
entirely and there's no room left for the CRC. If it's that important, the
PMD should fail to create the Rx queue in that case as well.
> ---
> drivers/net/mlx5/mlx5_rxq.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
> index 6b29aae..701925b 100644
> --- a/drivers/net/mlx5/mlx5_rxq.c
> +++ b/drivers/net/mlx5/mlx5_rxq.c
> @@ -887,6 +887,8 @@ struct mlx5_rxq_ctrl*
> const uint16_t desc_n =
> desc + priv->rx_vec_en * MLX5_VPMD_DESCS_PER_LOOP;
> unsigned int mb_len = rte_pktmbuf_data_room_size(mp);
> + uint8_t crc_size =
> + !!(dev->data->dev_conf.rxmode.hw_strip_crc == 0) << 2;
>
> tmpl = rte_calloc_socket("RXQ", 1,
> sizeof(*tmpl) +
> @@ -900,12 +902,13 @@ struct mlx5_rxq_ctrl*
> /* Enable scattered packets support for this queue if necessary. */
> assert(mb_len >= RTE_PKTMBUF_HEADROOM);
> if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=
> - (mb_len - RTE_PKTMBUF_HEADROOM)) {
> + (mb_len - RTE_PKTMBUF_HEADROOM - crc_size)) {
> tmpl->rxq.sges_n = 0;
> } else if (dev->data->dev_conf.rxmode.enable_scatter) {
> unsigned int size =
> RTE_PKTMBUF_HEADROOM +
> - dev->data->dev_conf.rxmode.max_rx_pkt_len;
> + dev->data->dev_conf.rxmode.max_rx_pkt_len +
> + crc_size;
> unsigned int sges_n;
>
> /*
> --
> 1.7.1
>
--
Adrien Mazarguil
6WIND