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 A3F55A0C40; Thu, 29 Jul 2021 08:40:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2772240DFB; Thu, 29 Jul 2021 08:40:14 +0200 (CEST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by mails.dpdk.org (Postfix) with ESMTP id 5E6B340687 for ; Thu, 29 Jul 2021 08:40:12 +0200 (CEST) Received: by mail-io1-f49.google.com with SMTP id a13so5687512iol.5 for ; Wed, 28 Jul 2021 23:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kukFkojo61qmZPBd58a+AWIGm3b3oGmxmTdz96ZiFPM=; b=b1ZWshqvkXcn684VaAgpHAEyLiGVy/l8PLR+kQgap+La74fMgImAhluDT7IRjx9b02 Vhe3RGK9ovYlOoeaSPMZKLiWzT3S5n1drwR2govUJ2EsRmsRVbz7u0SV3D311kBRo7ab hgJKiiWHjr/YWS4GY4QJaUvtlItUH6Ks59m1mWZVMRkZ7t8IoAWmKoyVTu95pea/ODmZ zZmg3rgPUfevPjaUq1Co1X6lSxprs2Y+du39ui+F3I875+NTIj6a2URbvbE2ypklnUtB b22NMbGp39BqfrMu+PG/toadzibq183iZGdD3TMF4uxa0Dhrivr3r5ELPRfU6DrG6F64 62RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kukFkojo61qmZPBd58a+AWIGm3b3oGmxmTdz96ZiFPM=; b=qydO6KsznH/UdV6BMxN7WOfeL7IB8QOU7fcrLu85EZ5zzNKTYr6KoZ4Erbdr5HmalU IB9U4L3bOCzD+U2/6wVGLzxH1O6MKDPJkBqbCaZ+yUvudPJzItQKdNmzafIP5cXNIuWh 4D86NSZp01u0K5UEPRnrruoT54NSTMVFc1Cni8Vu4pfz/KUc7F2afHanWX5KQQn252lS 7YA8jTQwDDj1Y9tIQrzMLQE+TCDijB9YdqY6GgJcHLed/9GdyFRpMl+ufBuTO+MN/+nc BxeuoIyluVl9eTeREdVgZANHM8mVDpePtTKHny/KMuf9/+4NU//0aC62xMSynGK8zLi4 /iyw== X-Gm-Message-State: AOAM531nGD2CAESOXmcSxh7sjYXap6FjMHl7w3q7Q0bCi/02LAys3TE8 49qZBbdz20ozaTROkL6+J5XTH6UGzpPsbt/irT84eg== X-Google-Smtp-Source: ABdhPJyEp2i9ucCMQMReMQIJBEQ0NQ98Lh2H1HmApTrt0rxuuf30nyKMpmwDgDiZKfkPE4Oi6Q3Qs4aXIdvhYGHEYAc= X-Received: by 2002:a5d:8996:: with SMTP id m22mr2810680iol.6.1627540811594; Wed, 28 Jul 2021 23:40:11 -0700 (PDT) MIME-Version: 1.0 References: <20210712170153.11508-1-ghalem.boudour@6wind.com> In-Reply-To: From: =?UTF-8?Q?Micha=C5=82_Krawczyk?= Date: Thu, 29 Jul 2021 08:40:00 +0200 Message-ID: To: Olivier Matz Cc: Ghalem Boudour , Marcin Wojtas , Guy Tzalik , Evgeny Schemeilin , Igor Chauskin , dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] net/ena: enable multi segment in Tx offload flags 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 Sender: "dev" =C5=9Br., 28 lip 2021 o 16:27 Olivier Matz napisa= =C5=82(a): > > Hi Micha=C5=82, > > On Wed, Jul 14, 2021 at 12:02:32PM +0200, Micha=C5=82 Krawczyk wrote: > > pon., 12 lip 2021 o 19:03 Ghalem Boudour nap= isa=C5=82(a): > > > > > > The DPDK ENA driver does not provide multi-segment tx offload capabil= ity. > > > Let's add DEV_TX_OFFLOAD_MULTI_SEGS to ports offload capability by de= fault. > > > > > > > Hi Ghalem, > > > > This patch enables announcement of the DEV_TX_OFFLOAD_MULTI_SEGS > > capability, but still the application may not request this offload. > > > > As ENA PMD currently assumes all the mbufs may have multiple segments > > (and we don't have fast-path for the other cases), I suggest > > overwriting this flag in the ena_dev_configure(), similar to what > > we're doing with the DEV_RX_OFFLOAD_RSS_HASH flag. > > To give some more context, our application currently checks if the > driver supports multi-segments by checking its capabilities, and asks > for the feature if it is advertised. > > When dealing with drivers that do not advertise this capability, our app > linearizes the segmented mbufs before sending them to the driver. > > I think this is the proper way to use the API: if the driver supports to > handle multisegmented mbufs, it should advertise the capability. > > Regards, > Olivier > Hi Olivier, I agree we should advertise it. However, after advertising this option, the application should ask PMD to use this feature if I understand the offload API correctly. I was thinking about the PMD behavior if this option won't be requested by the application - it would be the same as for the multisegment setup, that's why I suggested to also override this feature at the configuration step. With the RSS hash feature we're doing exactly the same - first we're advertising that it's available, and then (if RSS was enabled), we're setting this offload as enabled, even though the application didn't request it explicitly. Anyway, I won't be holding push of this patch as we're close to rc3. @Ghalem, please add the fixline and Cc the dpdk@stable.org in the commit log, so we will have this commit backported. Thanks, Michal