2016-12-01 08:15, Adrien Mazarguil: > I'm perhaps a bit pessimistic mind you, but I do not think tx_prepare() will > remain optional for long. Sure, PMDs that do not implement it do not care, > I'm focusing on applications, for which the performance impact of calling > tx_prepare() followed by tx_burst() is higher than a single tx_burst() > performing all the necessary preparation at once.
I agree that tx_prepare() should become mandatory shortly. > [...] > > > Following the same logic, why can't such a thing be made part of the TX > > > burst function as well (through a direct call to rte_phdr_cksum_fix() > > > whenever necessary). From an application standpoint, what are the > > > advantages > > > of having to: > > > > > > if (tx_prep()) // iterate and update mbufs as needed > > > tx_burst(); // iterate and send > > > > > > Compared to: > > > > > > tx_burst(); // iterate, update as needed and send > > > > I think that was discussed extensively quite a lot previously here: > > As Thomas already replied - main motivation is to allow user > > to execute them on different stages of packet TX pipeline, > > and probably on different cores. > > I think that provides better flexibility to the user to when/where > > do these preparations and hopefully would lead to better performance. > > And I agree, I think this use case is valid but does not warrant such a high > penalty when your application does not need that much flexibility. Simple > (yet conscious) applications need the highest performance. Complex ones as > you described already suffer quite a bit from IPCs and won't mind a couple > of extra CPU cycles right? > > Yes they will, therefore we need a method that satisfies both cases. > > As a possible solution, a special mbuf flag could be added to each mbuf > having gone through tx_prepare(). That way, tx_burst() could skip some > checks and things it would otherwise have done. I like this idea!
