From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 5E6155A8D for ; Tue, 9 May 2017 15:40:11 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id w50so73664243wrc.0 for ; Tue, 09 May 2017 06:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vSoa9PELk0yaGftwu55QinuL6Gz8Fv07lErjgH29cgw=; b=EhdR0yhzMkCduNe8AxvCFohxvgmcSBKTCzOMVnLBRPl3mzB9fThn1jebtA2TklcFYg K7xa2x7ckgguQgWFL4BZhrlpCYG5Let67eb2Iy5V33ErKiwKC3uztCPWM69dOJxYrNwd Y/mExpWiqbOQ4jb/yaqqozN40kpj8s9ULoSD2szC7peJelRqOvLl5BegkkJ1CqIGH3t5 GNm3UbhQl5qZtBl+sRLvE3QjoPRnrnXjD2KK3euV8Ieja04Xw8Sdw14+Uu1NdvUEgkXL MP7sfwXzAiGka3+aEnz0vsAew0NSd7IK2VdpywRNJr0NSZrzZrlqjIhUBx5lCxp3GEp2 Ixqg== 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:in-reply-to; bh=vSoa9PELk0yaGftwu55QinuL6Gz8Fv07lErjgH29cgw=; b=YLyeUph482oynxczRyUb+mqSLZydsxa9L9yayqqnEeD2w3j7gsDSoE+HemvMKyJ7M6 G1D1TTQeQAbSEnwAGccXo4K87aZ+K3SweR62nhnXrNDSy9dYq80geWafyPQCfvV3avGv MQ+PjI0QUkZKxZ0abIqBZlJHDSVGoqavfWpISZZZnKRMKYBfdzEvxhfjge7bSgP4MUYN T1X1MV68ZlOsp1XgrGRp8xye3l7/J5BRKVkkibGz4ZFx4ImDPk0lEo9UMWmag80oivCb He3Dgqw895a8WtHbocrAeOoL/uDMQKxWDZJJdutZSHw9OQpbfNNsNP8rAqJhHKGyQiYt AI/Q== X-Gm-Message-State: AODbwcAYUd1PZE+G/E1EmZ9ADBNGw72fBzXwPNwAT/BYfsVaWlFXFxB5 PYxq4QvmrIumKvKVU6Y= X-Received: by 10.223.172.165 with SMTP id o34mr52863wrc.155.1494337211151; Tue, 09 May 2017 06:40:11 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id t30sm15795182wrc.24.2017.05.09.06.40.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 06:40:10 -0700 (PDT) Date: Tue, 9 May 2017 15:40:04 +0200 From: Adrien Mazarguil To: Shahaf Shuler , Konstantin Ananyev , Olivier Matz , Tomasz Kulasek Cc: dev@dpdk.org Message-ID: <20170509134004.GO16218@6wind.com> References: <20170501065812.5185-1-shahafs@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170501065812.5185-1-shahafs@mellanox.com> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change on ethdev X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:40:11 -0000 On Mon, May 01, 2017 at 09:58:12AM +0300, Shahaf Shuler wrote: > This is an ABI change notice for DPDK 17.08 in librte_ether > about changes in rte_eth_txmode structure. > > Currently Tx offloads are enabled by default, and can be disabled > using ETH_TXQ_FLAGS_NO* flags. This behaviour is not consistent with > the Rx side where the Rx offloads are disabled by default and enabled > according to bit field in rte_eth_rxmode structure. > > The proposal is to disable the Tx offloads by default, and provide > a way for the application to enable them in rte_eth_txmode structure. > Besides of making the Tx configuration API more consistent for > applications, PMDs will be able to provide a better out of the > box performance. > Finally, as part of the work, the ETH_TXQ_FLAGS_NO* will > be superseded as well. > > Signed-off-by: Shahaf Shuler Basically, TX mbuf flags like TSO and checksum offloads won't have to be honored by PMDs unless applications request them first while configuring the device, just like RX offloads. Considering more and more TX offloads will be added over time, I do not think expecting them all to be enabled by default is sane. There will always be an associated software cost in PMDs, and this solution allows applications to selectively enable them as needed for maximum performance. Konstantin/Olivier/Tomasz, I do not want to resume the thread about tx_prepare(), however this could provide an alternative means to benefit from improved performance when applications do not need TSO (or any other offload for that matter), while adding consistency to device configuration. What's your opinion? In any case I'm fine with this change: Acked-by: Adrien Mazarguil > --- > doc/guides/rel_notes/deprecation.rst | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index a3e7c720c..0920b4766 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -81,3 +81,11 @@ Deprecation Notices > > - ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get`` > - ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set`` > + > +* ethdev: in 17.08 ABI changes are planned: > + Tx offloads will no longer be enabled by default. > + Instead, the ``rte_eth_txmode`` structure will be extended with bit field to enable > + each Tx offload. > + Besides of making the Rx/Tx configuration API more consistent for the > + application, PMDs will be able to provide a better out of the box performance. > + as part of the work, ``ETH_TXQ_FLAGS_NO*`` will be superseded as well. > -- > 2.12.0 > -- Adrien Mazarguil 6WIND