Re: [dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Mon,  7 Aug 2017 13:54:27 +0300
> From: Shahaf Shuler <shahafs@mellanox.com>
> To: dev@dpdk.org
> Subject: [dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API
> X-Mailer: git-send-email 2.12.0
> 
> Tx offloads configuration is per queue. 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
> configuration is per port. Rx offloads are disabled by default and enabled 
> according to bit field in rte_eth_rxmode structure.
> 
> Moreover, considering more Tx and Rx offloads will be added 
> over time, the cost of managing them all inside the PMD will be tremendous,
> as the PMD will need to check the matching for the entire offload set 
> for each mbuf it handles.
> In addition, on the current approach each Rx offload added breaks the
> ABI compatibility as it requires to add entries to existing bit-fields.
>  
> The RFC address above issues by defining a new offloads API.
> With the new API, Tx and Rx offloads configuration is per queue.
> The offloads are disabled by default. Each offload can be enabled or
> disabled using the existing DEV_TX_OFFLOADS_* or DEV_RX_OFFLOADS_* flags.
> Such API will enable to easily add or remove offloads, without breaking the
> ABI compatibility.
> 
> The new API does not have an equivalent for the below Tx flags:
> 
> * ETH_TXQ_FLAGS_NOREFCOUNT
> * ETH_TXQ_FLAGS_NOMULTMEMP

IMO, it make sense to keep those flags as PMD optimization if an application
does not need reference count and multi mempool in the application.
As example, An non trivial application like l3fwd does not need both of them.