From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9E92D425FC for ; Tue, 19 Sep 2023 10:15:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 967904028B; Tue, 19 Sep 2023 10:15:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 5FD644027E for ; Tue, 19 Sep 2023 10:15:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695111327; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NhXaVH8t6kUF/Eaj7mgV9KnC9MB+tiiMdD9N/xKcVtY=; b=g78YtqW3pDKGRbQMBW4Pat0Qw5//11TB05UEHt1F9iEf7JjZDTSITizkFHua6+u9RD76JM 8xiTGtWDhUHxSAv2XJGhSeawMVTQZF4hhQKX0vZEu6OJ5GWNWDLhb+Oeb/0Pe8xctuaWDu Z6BqrWD4rQyRP/iPv9nI5hVaLyd86WA= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-H4nTujPQPle97ioP_s8IOw-1; Tue, 19 Sep 2023 04:15:26 -0400 X-MC-Unique: H4nTujPQPle97ioP_s8IOw-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2b6ff15946fso67245291fa.2 for ; Tue, 19 Sep 2023 01:15:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695111325; x=1695716125; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NhXaVH8t6kUF/Eaj7mgV9KnC9MB+tiiMdD9N/xKcVtY=; b=L0Z9lbcI/O5ob2+RJvc5y5s4z3deuXWCIRSOQ9tytyURYgN6o8atNa9mXUyRCDHY3r 6IbfNhM3qsKR+TDWJAkJEWCwtAuoZK803h94kpyWnxPkagsjpy17yqErTUQO2T0OQZKr Olunhiek4z1WoRI3rjgz1LEp8YU+3iHFBbMmtB//7FwMgvv1UuraY5X8DJMYBfwVCjTm EECMAalLZ4XTuBbosjKWcvX9Qfs2JiRx8pMHpjFMPjwHRuCyU14+ziK6+TiamfHjJXi6 Guoqsdh2BTNKwx0tdLc+eHmeDjQS2U/+GMEYP9ql9CdGj8e1jocfafzNsSk/bOcPFMEo Ebyw== X-Gm-Message-State: AOJu0YwsDA4oxyXjQFezlieOeDRODti2ZfpEm5p23wMHGM4Q8IqSCuJz D9RIMF16+Lkg48Hg8LLCRmqrLKKHvCorWlNkjeF4UqhzU3sG4fL5xEYL6HDLR8Uzuip54yO2qye mIwLS8bv5F7R6FENdxrUDCrE= X-Received: by 2002:a2e:b55a:0:b0:2c0:26e1:275 with SMTP id a26-20020a2eb55a000000b002c026e10275mr1036697ljn.21.1695111325036; Tue, 19 Sep 2023 01:15:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHpeippiJlc4/XEoI40Jbf6dwDodJLki7N0LC3KU5sx+WJ4npNgN9SLNyNltTWeX0IZfo9fsr62aek7afOrMpk= X-Received: by 2002:a2e:b55a:0:b0:2c0:26e1:275 with SMTP id a26-20020a2eb55a000000b002c026e10275mr1036680ljn.21.1695111324704; Tue, 19 Sep 2023 01:15:24 -0700 (PDT) MIME-Version: 1.0 References: <20221111120401.802805-2-mingjinx.ye@intel.com> <20221111161241.861732-1-mingjinx.ye@intel.com> <20221111161241.861732-2-mingjinx.ye@intel.com> In-Reply-To: <20221111161241.861732-2-mingjinx.ye@intel.com> From: David Marchand Date: Tue, 19 Sep 2023 10:15:13 +0200 Message-ID: Subject: Re: [PATCH v4 2/2] net/ice: fix scalar Tx path segment To: Mingjin Ye , qiming.yang@intel.com, Qi Zhang Cc: dev@dpdk.org, stable@dpdk.org, yidingx.zhou@intel.com, Jingjing Wu , Ferruh Yigit , Wenzhuo Lu , Kevin Liu X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hello, Replying on this old thread, as it seems no in depth review was done but I need more info before fixing a bug added by ccf33dccf7aa ("net/ice: check illegal packet sizes"). On Fri, Nov 11, 2022 at 9:26=E2=80=AFAM Mingjin Ye = wrote: > > The scalar Tx path would send empty buffer that causes the Tx queue to > overflow. This is too vague. Please describe the exact issue. Is it a sw (read net/ice driver) bug? a hw bug? > > This patch adds the last buffer length judgment in tx_prepare to fix this This reads odd. The added code will stop and return an error when the last segment *that is evaluated by the code* is empty. But on the other hand, it is easier to understand that the check is to catch the *first* empty segment of a packet. > issue, rte_errno will be set to EINVAL and returned if the last buffer is > empty. > > Fixes: 17c7d0f9d6a4 ("net/ice: support basic Rx/Tx") > Fixes: ccf33dccf7aa ("net/ice: check illegal packet sizes") > Cc: stable@dpdk.org > > Signed-off-by: Mingjin Ye > > v3: > * delete unused variable. > * Full detection of mbufs. > --- > drivers/net/ice/ice_rxtx.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c > index e6ddd2513d..9017353943 100644 > --- a/drivers/net/ice/ice_rxtx.c > +++ b/drivers/net/ice/ice_rxtx.c > @@ -3643,6 +3643,22 @@ ice_set_tx_function_flag(struct rte_eth_dev *dev, = struct ice_tx_queue *txq) > #define ICE_MIN_TSO_MSS 64 > #define ICE_MAX_TSO_MSS 9728 > #define ICE_MAX_TSO_FRAME_SIZE 262144 > + > +/*Check for empty mbuf*/ Missing spaces. > +static inline uint16_t > +ice_check_empty_mbuf(struct rte_mbuf *tx_pkt) This function name is confusing. In dpdk, a mbuf can be both a segment descriptor (part of a packet) or a packet descriptor (in which case, it overlaps the first segment descriptor). So it is better to be explicit with "segment" or "packet" when referring to a mbuf. > +{ > + struct rte_mbuf *txd =3D tx_pkt; > + > + while (txd !=3D NULL) { > + if (txd->data_len =3D=3D 0) > + return -1; > + txd =3D txd->next; > + } There is nothing in the API that says that an empty segment is faulty. With the current description, I understand that any empty segment could lead to a bug, regardless of asking offloads (which ice_prep_pkts is all about). So a more valid fix is probably to skip empty segments in the tx handler function(s) and not reject packets in ice_prep_pkts. Another option could be to fix this "overflow" mentionned in the commitlog. Looking fwd to explanations. > + > + return 0; > +} > + > uint16_t > ice_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts, > uint16_t nb_pkts) --=20 David Marchand