28/08/2017 07:00, Jerin Jacob: > From: Shahaf Shuler <shah...@mellanox.com> > > Friday, August 25, 2017 1:32 PM, Jerin Jacob: > > > > > > > > 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. > > > > The l3fwd application is yet another simple example from DPDK tree. Am not > > sure that a complete vRouter/vSwitch implementation is with the same > > characteristics. > > But not all dpdk applications are complete vRouter/vSwitch implementation. > > > Moreover, I think the fact there is an application which is able to use it > > is not enough. IMO there needs to be some basic functionality always > > provided by the PMDs and not controlled by flags. > > For example, let's say we have an application which always sends the mbufs > > with the same ol_flags, or even with the same length. > > Does ETH_TXQ_FLAGS_NOREFCOUNT comes in same category like mbuf->ol_flags? > > > Will it make sense to add more flags to control it? > > Will it makes sense to run RFC2544 benchmark with testpmd io forwarding > > with those flags? > > > > If the answer is yes, maybe those flags (and others to follow) belong on > > different location on ethdev. However for sure they are not offloads. > > I am not sure about the reason for opting out mempool related flags. > In the context of HW assisted external mempool managers, Enabling reference > count is an offload > from Ethernet device. > For example, with external HW assisted mempool, ethdev driver needs to > have different way of forming TXQ descriptor in case if reference count > is enabled(as, in the case of HW assisted mempool managers, bu default, > HW frees the packet on send) > > I am fine with moving the flags to some where else if it is make sense to > you.But > from PMD optimization perspective, I think it is important have these flags.
Why not. Please Jerin, could you work on moving these settings in a new API? We can have a function to enable such optimizations. However I am not sure ethdev is the right place as these hints apply to any mbuf. Other related question: what happens if other libraries manipulate these mbufs with special optimization hints? Should they be aware?
