From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 2B9FF2C66 for ; Mon, 4 Sep 2017 16:57:07 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id i145so6373090wmf.1 for ; Mon, 04 Sep 2017 07:57:07 -0700 (PDT) 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:content-transfer-encoding:in-reply-to :user-agent; bh=Y+oQ5SodHqjF2TIUK+uOpgHXZOpnbCtc3A2Pbe3WQqQ=; b=gi/Ed4tbhM9E+KD8Eqo1NtdQkBCtj++0fTycWAbeq8sq2LTBnCJITzSlKzIpBMnjNh 5kJYC5L0PF/kBkFIutXQhCMp4V34Ll1TNPwZs6Hx1SV51ZJjBU1bJTMapMilSp9Rc6xu TYfOaPaN4PNZs+um/11p+m507jrFlJRKVwoggnnIy6+EcnRaODToI5sDomlGC1roJ2f3 JtaAnK1k/B/i8ZSh3+4H2D7mijEgk3zXu0GiXf0Ks2znoahETte9BEbc/IukgEWKMHAT hz7KEoaRcYFnVEfVSi0qpuMRDY1gmtbB/hGbDwT0wbupwJpYh1UvftAldgsKSt9cbxYE 0QZA== 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:content-transfer-encoding :in-reply-to:user-agent; bh=Y+oQ5SodHqjF2TIUK+uOpgHXZOpnbCtc3A2Pbe3WQqQ=; b=S0201ORqfqKKa0JYzk45te2xJ2wbI7cxtZDPfgzwbrloPrzRkeUj5TJVYvm/aGumaR j8xjt8EfQQg1plV0KyZWypkpjbDn8sVOazgU231DyRq/NKEoTjgrmwGPdHxEq1RTQZfj Xql4rO8rw8uKDgp9PdgurY524qBoEXAz/SLBxmMMANhjRrepn4anq+WJLjbcL3BJNelk cStYf4FvhSSIbI1YdFw5GiOTsuYBjCvMVWTgaXyc6lw+3gr7WbkBxYXVLEeITK6ezkAD +JQ05SatdA9Nt6Xn7x24MIzVuT7FpEgG0DS+Q5s/BFOg6VD5EuZV7cXP4sKxdH3GFiQW nWkQ== X-Gm-Message-State: AHPjjUhYoutDf+Gr52+RCDGLI99Qukj9EyubLDX1pZrVuR342SwxGfqt 2WNSZ1ogePgIkoB8 X-Google-Smtp-Source: ADKCNb6IsXrGdU1QZbh7pSW9dIpVo59irUO/FMojGe2YOv25WhKxiFRFHEbaAOXdnJMDFxN2BS9Ghg== X-Received: by 10.28.232.82 with SMTP id f79mr660022wmh.179.1504537026777; Mon, 04 Sep 2017 07:57:06 -0700 (PDT) Received: from localhost (lan31-h07-89-80-147-20.dsl.sta.abo.bbox.fr. [89.80.147.20]) by smtp.gmail.com with ESMTPSA id s15sm6047235wrg.84.2017.09.04.07.57.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Sep 2017 07:57:06 -0700 (PDT) Date: Mon, 4 Sep 2017 16:57:04 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Shahaf Shuler Cc: adrien.mazarguil@6wind.com, dev@dpdk.org, stable@dpdk.org Message-ID: <20170904145703.3d7onktokegfo2dm@localhost> References: <20170823073358.116786-1-shahafs@mellanox.com> <22e16781b4231bc202a377f95e51cdeb999598bf.1504076528.git.shahafs@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <22e16781b4231bc202a377f95e51cdeb999598bf.1504076528.git.shahafs@mellanox.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-stable] [PATCH v2 2/2] net/mlx5: enforce Tx num of segments limitation 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: Mon, 04 Sep 2017 14:57:07 -0000 On Wed, Aug 30, 2017 at 10:07:08AM +0300, Shahaf Shuler wrote: > Mellanox NICs has a limitation on the number of mbuf segments a multi > segment mbuf can have. The max number depends on the Tx offloads requested. > > The current code not enforce such limitation, which might cause > malformed work requests to be written to the device. > > This commit adds verification for the number of mbuf segments posted > to the device. In case of overflow the packet will not be sent. > Debug prints were added to help application identify the cause for such > case. > > In addition update the nic documentation with the limitation. > Considering device limitation is 63 data segments in a work request, the > maximum number of segment in mbuf was calculated taking TSO as the worst > case: > > max_nb_segs = 63 - (control_segment + ethernet segment + > TSO headers inline + inline segment + > extra inline to align to cacheline) > > Cc: stable@dpdk.org > > Signed-off-by: Shahaf Shuler > --- > This patch should be applied only after the series: > http://dpdk.org/dev/patchwork/patch/27367/ > > on v2: > - remove parenthesis around MLX5_MAX_DS. > - add limitation to nic guide. > - update commit message. > - fix typo. > --- > doc/guides/nics/mlx5.rst | 2 ++ > drivers/net/mlx5/mlx5_defs.h | 3 ++- > drivers/net/mlx5/mlx5_prm.h | 3 +++ > drivers/net/mlx5/mlx5_rxtx.c | 30 +++++++++++++++++++++++++++--- > drivers/net/mlx5/mlx5_rxtx_vec_sse.c | 8 ++++++++ > drivers/net/mlx5/mlx5_txq.c | 27 +++++++++++++++++++++++++++ > 6 files changed, 69 insertions(+), 4 deletions(-) > > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst > index f4cb18bca..d8244de97 100644 > --- a/doc/guides/nics/mlx5.rst > +++ b/doc/guides/nics/mlx5.rst > @@ -124,6 +124,8 @@ Limitations > > Will match any ipv4 packet (VLAN included). > > +- A multi segment mbuf must have less than 50 segments. That means mbuf->nb_segs < 50. > + > Configuration > ------------- > > diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h > index a76bc6f65..3de0e5d81 100644 > --- a/drivers/net/mlx5/mlx5_defs.h > +++ b/drivers/net/mlx5/mlx5_defs.h > @@ -100,7 +100,8 @@ > > /* > * Maximum size of burst for vectorized Tx. This is related to the maximum size > - * of Enhaned MPW (eMPW) WQE as vectorized Tx is supported with eMPW. > + * of Enhanced MPW (eMPW) WQE as vectorized Tx is supported with eMPW. > + * Careful when changing, large value can cause wqe DS to overlap. > */ > #define MLX5_VPMD_TX_MAX_BURST 32U > > diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h > index 608072f7e..bc2b72333 100644 > --- a/drivers/net/mlx5/mlx5_prm.h > +++ b/drivers/net/mlx5/mlx5_prm.h > @@ -154,6 +154,9 @@ > /* Default mark value used when none is provided. */ > #define MLX5_FLOW_MARK_DEFAULT 0xffffff > > +/* Maximum number of DS in WQE. */ > +#define MLX5_MAX_DS 63 > + > /* Subset of struct mlx5_wqe_eth_seg. */ > struct mlx5_wqe_eth_seg_small { > uint32_t rsvd0; > diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c > index fe9e7eac0..d7aa382f9 100644 > --- a/drivers/net/mlx5/mlx5_rxtx.c > +++ b/drivers/net/mlx5/mlx5_rxtx.c > @@ -657,6 +657,15 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n) > else > j += sg; > next_pkt: > + if (ds > MLX5_MAX_DS) { > +#ifndef NDEBUG > + WARN("Cannot send packet %p with %d segments " > + "wqe.ds = %d, wqe.inline_sz = %d", > + (void *)pkts, (*pkts)->nb_segs, ds, > + pkt_inline_sz); > +#endif I will say no for those series of warning in the datapath, I understand the need of such informations, but it will reduce considerably the throughput in some cases where the issue is not related to this. Datapath must also be optimised also in debug mode. I suggestion would be to change the burst API to return an int with correct errors values. Currently oerrors can be increased in such situation to provide more information to the user. Thanks, -- Nélio Laranjeiro 6WIND