Monday, January 15, 2018 12:21 PM, Ferruh Yigit: > > I think all of the 3 should be in a single patch. > > The reason is that the convert patch should maintain the same offloads > configuration needed for the application. > > Perhaps I am missing some details about "mbuf fast free" offload, can you > please give more details about it, what does having or not having it mean? > Currently no PMD seems implemented it.
Sure, FAST_FREE offload is the logical AND between the old txqflags of: ETH_TXQ_FLAGS_NOREFCOUNT ETH_TXQ_FLAGS_NOMULTMEM The offload is just a performance optimization. As specified in the documentation [1] it enables the PMDs to further optimize the data path given the guarantees from the application. Not having it means possible performance degradation for some PMD which rely on it. There is no PMD which implement it yet since not all PMDs moved to the new offloads API. However this flag is tested and translated into txqflags as part of rte_eth_convert_txq_offloads function. Relevant PMDs for this offload will be: sfc, thunderx and i40e. [1] /**< Device supports optimization for fast release of mbufs. * When set application must guarantee that per-queue all mbufs comes from * the same mempool and has refcnt = 1. */ > > > Before the convert patch the examples were using the default > configuration set by the PMD. In there the txq flags were set to ignore ref > count and to declare all mbufs are from the same pool. > > The fast free Tx offload was added in order to keep this old offloads > configuration. > > > >> > >> Wouldn't be better to enable new offloadings in a separate patch, > >> other than convert one? And I don't know if we want to enable that > >> specific offload for all samples. > > > > As you can see, not all the examples has the FAST_FREE offloads, only the > entitled ones (i.e. single mempool and no ref count). > > For example, ipv4_multicast doesn't set this offload flag. > >
