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 B5A1942651; Wed, 27 Sep 2023 10:45:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82BA74026C; Wed, 27 Sep 2023 10:45:11 +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 C0AB74026B for ; Wed, 27 Sep 2023 10:45:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695804309; 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=i+SYga2XOkjZolTRp5Cd+uwCjk9H2GShytG4M40d9eM=; b=Dl7Je7i4CObCXxESLtebBmom0sAYcygoKblZhDrx2qZALm/WdmlZ62mmHTsZKzR8Htncoc +8XnQJSgS7Z4hWIWbWD+Ggtmwx1TwqIhVReNlgw/ExLqU8ujtDQuC4tjCIgEvqthgxWMt7 IFtWlGUbk5cT1M9ww7baSZsTd2oge1I= 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-556-9iVfwsEbOI6H7mMZbn0qmQ-1; Wed, 27 Sep 2023 04:45:07 -0400 X-MC-Unique: 9iVfwsEbOI6H7mMZbn0qmQ-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2c01ce3c29fso163805101fa.3 for ; Wed, 27 Sep 2023 01:45:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695804306; x=1696409106; 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=i+SYga2XOkjZolTRp5Cd+uwCjk9H2GShytG4M40d9eM=; b=gBys3IH957TQNL3YFxPhDM4Mwx+LonxeHjMB/bMXQ5NckbY21NHDMTwDOvv1X7Gv4u KGkpiympePbHulrxSZz2DmY6NoP/uF0PI77k8xs1DtKs7RtjBYQ2QwXiE7Hi7qkpX7O8 +58fS0/rWPEGEuVmZMtNy7RTphT4a7S/Z1lto+OPIMGK58hDeptV9am1SPuhrPnWLYbd 18qkjrZONxX20VWiZXuz8upyrgmyTf04kbTmLua8U0HJW5yOt2bMmFBGdn3tWGLrc+B7 3tInEgwu9erUI+k4wv+aMFf+8N7gVJwPMFKi4OnS0j1WA7rp2Lg71pADyk202JFqs0WI PBcQ== X-Gm-Message-State: AOJu0YwdQa8ylCPgtCegFLR9YwpFwLtLlsIF/33gO7feYWA+P5lpPIty Pua+nTj8brC923oKQBCsw7jaNTUb97yYhtjs3iPU7qDZDc0StM50GavohWXYR4jyuNFZzyFmfuC SO30WVhVo7VHS/0dq3KI= X-Received: by 2002:a05:651c:1034:b0:2bc:c4af:36b9 with SMTP id w20-20020a05651c103400b002bcc4af36b9mr1234268ljm.52.1695804306549; Wed, 27 Sep 2023 01:45:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFXIidXgPQALXPp48Dj2OUV+HhimaKRZIHxy0X6o0r2lSg9IO8YMnYBPcMt7lqbTLVYveApfiKHspcIqKLSjCI= X-Received: by 2002:a05:651c:1034:b0:2bc:c4af:36b9 with SMTP id w20-20020a05651c103400b002bcc4af36b9mr1234253ljm.52.1695804306127; Wed, 27 Sep 2023 01:45:06 -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: From: David Marchand Date: Wed, 27 Sep 2023 10:44:54 +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: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Sep 19, 2023 at 10:15=E2=80=AFAM David Marchand wrote: > 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 th= is > > 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 commitlo= g. > > Looking fwd to explanations. Ping. --=20 David Marchand