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 8955642602; Thu, 21 Sep 2023 07:55:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0FF234026D; Thu, 21 Sep 2023 07:55:26 +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 51DE24026D for ; Thu, 21 Sep 2023 07:55:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695275723; 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=rEt0hafxNcNaiYYQEcUEdKVVlm7zRfgToVI4juAmT+4=; b=YRetrBOrYDWKwA15vXwkE4FjZr8FXpNbu9WOXXYO/+wZPzWcVIH24QmCmFYtPy3kLRbhyl Jg/qHYDBeuuvlUrJCJ56CG6tNOQL3ZCrBOxIDnqScsbfgipyQ0LcKVTu1sO6VcNZ9SDzWX mbBtFyl08nvttYHlAyuOJnPxV4434pY= 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-280-RbjIeCP0OfKA3eQiNRP_4Q-1; Thu, 21 Sep 2023 01:55:21 -0400 X-MC-Unique: RbjIeCP0OfKA3eQiNRP_4Q-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2bffb48a78cso11691781fa.0 for ; Wed, 20 Sep 2023 22:55:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695275720; x=1695880520; 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=rEt0hafxNcNaiYYQEcUEdKVVlm7zRfgToVI4juAmT+4=; b=Rn4q5zgqPlCy78n5Fk4CLeadq6R5M3gJTV9jYwnBFB+pIUwPgMi3qWRqNcZP86v+sT At5r5Omt39waT+XM161M+UafP3a5seT3U+duiICOR09R1t8qZsLAUPtSXEgk9fsNHI0l 1WBft/JOGNmGFS1I0N1TCsdVfUSEHoXfJ82mEGL4M8S3iHMGl/4Co+ZEhHvAZM7eDhF2 O4NX177WX2IDfRoq/+mJLfS7OttwNFFBKn6DduCBQsn8KyxU3ZStxLya4qtEux5VkoVi 4TEz6Oh0njvkhdq2Q85lhMUpu9cqAijfKN8AhvnlQGsytgY/zIaVLpLrl6n38dyIZFs1 nG7w== X-Gm-Message-State: AOJu0YxlldGvLYcjtdrz4drEe2ManAUZccy7U2O7LiYvlw0ZW6oHVQwt 9QDXQrqxSfNAL/XcprAuujkt9aTnqNfglrqsJN5KTFddVeEFRRL4ouj1eoeeF/Q+GQTemcOyHUb hkytSAiUpIDqsjnVemZ0= X-Received: by 2002:a2e:380a:0:b0:2bf:f985:7729 with SMTP id f10-20020a2e380a000000b002bff9857729mr1857915lja.17.1695275720522; Wed, 20 Sep 2023 22:55:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGTLs/V9cxfIVKsQ7hXVF4v94GNPaP38opNEsH4e9zBBxYRgdI5CaVwisHgNVSQ2A8OULsAGBXwMmY/9qTx+G0= X-Received: by 2002:a2e:380a:0:b0:2bf:f985:7729 with SMTP id f10-20020a2e380a000000b002bff9857729mr1857908lja.17.1695275720198; Wed, 20 Sep 2023 22:55:20 -0700 (PDT) MIME-Version: 1.0 References: <20230919140430.3251493-1-david.marchand@redhat.com> <20230919140430.3251493-2-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Thu, 21 Sep 2023 07:55:08 +0200 Message-ID: Subject: Re: [PATCH 2/2] net/ice: fix TSO with big segments To: "Zhang, Qi Z" Cc: "dev@dpdk.org" , "ktraynor@redhat.com" , "mkp@redhat.com" , "dexia.li@jaguarmicro.com" , "stable@dpdk.org" , "Yang, Qiming" , 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 Thu, Sep 21, 2023 at 7:48=E2=80=AFAM Zhang, Qi Z = wrote: > > > > > -----Original Message----- > > From: David Marchand > > Sent: Tuesday, September 19, 2023 10:05 PM > > To: dev@dpdk.org > > Cc: ktraynor@redhat.com; mkp@redhat.com; dexia.li@jaguarmicro.com; > > stable@dpdk.org; Yang, Qiming ; Zhang, Qi Z > > ; Kevin Liu > > Subject: [PATCH 2/2] net/ice: fix TSO with big segments > > > > Packets to be segmented with TSO are usually larger than MTU. > > Plus, a single segment for the whole packet may be used: in OVS case, a= n > > external rte_malloc'd buffer is used for packets received from vhost-us= er > > ports. > > > > Before this fix, TSO packets were dropped by net/ice with the following > > message: > > 2023-09-18T13:34:31.064Z|00020|dpdk(pmd- > > c31/id:22)|ERR|ice_prep_pkts(): > > INVALID mbuf: bad data_len=3D[2962] > > > > Remove the check on data_len. > > > > Besides, logging an error level message in a datapath function may slow > > down the whole application. It is better not to log anything. > > > > Fixes: ccf33dccf7aa ("net/ice: check illegal packet sizes") > > Cc: stable@dpdk.org > > > > Signed-off-by: David Marchand > > --- > > Note: there may be some followup patch later, as some additional check = has > > been added in ice_prep_pkts. > > For context, see: > > http://inbox.dpdk.org/dev/CAJFAV8yOa3ShkVdEXHfnmOEmUTwV3e75Bu9U3 > > OqpNc5usTt3Rw@mail.gmail.com/T/#u > > > > --- > > drivers/net/ice/ice_rxtx.c | 8 +------- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c in= dex > > 64c4486b4b..80c4284200 100644 > > --- a/drivers/net/ice/ice_rxtx.c > > +++ b/drivers/net/ice/ice_rxtx.c > > @@ -3685,9 +3685,6 @@ ice_prep_pkts(__rte_unused void *tx_queue, > > struct rte_mbuf **tx_pkts, > > int i, ret; > > uint64_t ol_flags; > > struct rte_mbuf *m; > > - struct ice_tx_queue *txq =3D tx_queue; > > - struct rte_eth_dev *dev =3D &rte_eth_devices[txq->port_id]; > > - uint16_t max_frame_size =3D dev->data->mtu + ICE_ETH_OVERHEAD; > > > > for (i =3D 0; i < nb_pkts; i++) { > > m =3D tx_pkts[i]; > > @@ -3704,11 +3701,8 @@ ice_prep_pkts(__rte_unused void *tx_queue, > > struct rte_mbuf **tx_pkts, > > return i; > > } > > > > - /* check the data_len in mbuf */ > > - if (m->data_len < ICE_TX_MIN_PKT_LEN || > > - m->data_len > max_frame_size) { > > + if (m->pkt_len < ICE_TX_MIN_PKT_LEN) { > > +1 > > > rte_errno =3D EINVAL; > > - PMD_DRV_LOG(ERR, "INVALID mbuf: bad > > data_len=3D[%hu]", m->data_len); > > is it still worth to keep a debug level log here ? and it's better to uni= fy the logging method in the same function. Logging data_len is incorrect. There are no log in other drivers. If anything, the logging may happen in the application invoking rte_eth_tx_prepare. I am against keeping those logs. --=20 David Marchand