From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id 3A4C61B6B0 for ; Fri, 10 Nov 2017 11:06:38 +0100 (CET) Received: by mail-wm0-f68.google.com with SMTP id n74so5234638wmi.1 for ; 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=nNYBCogvD03uu9gNleLPoTcrOtPEl9CQYzlnenH1ExFDeU59/Ig95fKFCgtyOD3M67 6IP+QdrBBcvwXxqzvXcpy5SmaRdXsXBeZpZHhdJIZyMb2yaOIVQZRiTdG6axeVsAr/nC sxhBBmQLa/wM8HxTse26PchwafjXLnKDB/DbjxMCxVYWQn13VWv4AydU5m0U644j47WE T7wFZsPy5EqXkkeQpcy2WvGza45Ia3KCewHh6UKNfqSY1XxAibzMTavxm0ryq82d99Zt 2c+wHfOYJgREcZttVzXRt0Emowz9EaUGr5+298xKJAHX3Pei0laZJAiT8Lp/FYpopc0D /tkA== X-Gm-Message-State: AJaThX5vKUj2Lan6nuVcpiTWviGsg9Gn9y6+t4h9hTJ0rgF3WxKkWcdj oGVqd7psl8+1RmzAkvnpVUWIoA== 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 To: Ori Kam 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-stable] [PATCH] net/mlx5: fix number of segment calculation X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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