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 71EFEA0C40; Thu, 29 Jul 2021 09:26:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DB4B840687; Thu, 29 Jul 2021 09:26:53 +0200 (CEST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by mails.dpdk.org (Postfix) with ESMTP id 1F7E240041 for ; Thu, 29 Jul 2021 09:26:53 +0200 (CEST) Received: by mail-wr1-f43.google.com with SMTP id d8so5615998wrm.4 for ; Thu, 29 Jul 2021 00:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=U/Iv03yLOR4Y4P6kQDhFPNkoUvrjGVLFvh0RJFaJSFg=; b=B5QAY89QS8FN2yRmwM+ItwPDnF/LNUyfV0z1LVUPTQUit0EMvkJYWgArdOyFFxtU/i Ic8inkitWaZzRvB6NZfG1wNvON7U4L8rpuRlxTNHI+bvYLw5T4zWxmT0c5hMKM6y1ylJ vTsn4l+/w1ShsGoOyb2OU1g9AHx5/v1g5qTlGdxOAGJF/Uq8cwk2KQq12/IyDNt6s0K3 2IEmXPJiIfr4LzdiDnLUcWfN7QBlTlbpoIxrV5K132s612CP3CxYzmwAcaE8ktfxAo+r GGLQpUV02xaHxfotVFfbw6KRaSt/0Z9nHQY94ZuO1xaa2YmnQ1HUVc/wbTVuSIDZURJl T+fw== 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; bh=U/Iv03yLOR4Y4P6kQDhFPNkoUvrjGVLFvh0RJFaJSFg=; b=h9OpVFAjXizZ175JgiCiSBi9vwhrJS+pySRXMz8wa506Ol/dCzilzIpKcyB9+9PZYo YqcZ+/eJ69LILkB4JtmThYQgmRNgK2pob1K9kyG6u7ZZ/MXbXF8xRtaZ1Grrn1dPqbEP GnyceODALzhoWGuc9VncsrHapaCBDbrrKwAuy97FJOuG7FIWeAitkPy7kN5dzXOfdH2O anWi+viloB3udjICJZnCWD8WY+nWd5KPOHNKtJ2jF7KoFv96G8x9ZlzacsP+On4O8den xBcRih0aB+0ufcYYi7S6X1ziscHaHPKPirm/d3ByLhdVmnnmUDjZ5OxHW2JAw/lRpv4s O7KA== X-Gm-Message-State: AOAM533AvMJSZ/fbNlNqOOwQnWTp6fHJ+/m/aLxIKJYU7FJPW/qyl9y9 iDcGfMSxDBE1jrewWcrg7PLb+A== X-Google-Smtp-Source: ABdhPJwtBg5Bgsw5MT7AwAgogD+VuroHQ6RjusYPHE0OlDLIwI+OXW5JQiDC2dHuFofSueDl8/FupQ== X-Received: by 2002:adf:f383:: with SMTP id m3mr3146278wro.81.1627543612830; Thu, 29 Jul 2021 00:26:52 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id n11sm2735989wrs.81.2021.07.29.00.26.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jul 2021 00:26:51 -0700 (PDT) Date: Thu, 29 Jul 2021 09:26:51 +0200 From: Olivier Matz To: =?utf-8?Q?Micha=C5=82?= Krawczyk Cc: Ghalem Boudour , Marcin Wojtas , Guy Tzalik , Evgeny Schemeilin , Igor Chauskin , dev Message-ID: References: <20210712170153.11508-1-ghalem.boudour@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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" Hi Michał, On Thu, Jul 29, 2021 at 08:40:00AM +0200, Michał Krawczyk wrote: > śr., 28 lip 2021 o 16:27 Olivier Matz napisał(a): > > > > Hi Michał, > > > > On Wed, Jul 14, 2021 at 12:02:32PM +0200, Michał Krawczyk wrote: > > > pon., 12 lip 2021 o 19:03 Ghalem Boudour napisał(a): > > > > > > > > The DPDK ENA driver does not provide multi-segment tx offload capability. > > > > Let's add DEV_TX_OFFLOAD_MULTI_SEGS to ports offload capability by default. > > > > > > > > > > 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. Yes > 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. I have no strong opinion here. If there is no behavior change when the option is set or unset by the application, I think both options are acceptable: either return what the application asked for, or return the option always set (as you do for hash). > 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. Ghalem is currently off, I'll take care of it. The multiseg Tx feature is there since the beginning, so the Fixes line will be: Fixes: 1173fca25af9 ("ena: add polling-mode driver") I can also add the flag in ena_dev_configure(), if you feel it is more consistent. Please let me know. Thanks, Olivier