2016-11-30 08:40, Adrien Mazarguil: [...] > I understand tx_prep() automates this process, however I'm wondering why > isn't the TX burst function doing that itself. Using nb_mtu_seg_max as an > example, tx_prep() has an extra check in case of TSO that the TX burst > function does not perform. This ends up being much more expensive to > applications due to the additional loop doing redundant testing on each > mbuf. > > If, say as a performance improvement, we decided to leave the validation > part to the TX burst function; what remains in tx_prep() is basically heavy > "preparation" requiring mbuf changes (i.e. erasing checksums, for now). > > 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 > > Note that PMDs could still provide different TX callbacks depending on the > set of enabled offloads so performance is not unnecessarily impacted. > > In my opinion the second approach is both faster to applications and more > friendly from a usability perspective, am I missing something obvious?
I think it was not clearly explained in this patchset, but this is my understanding: tx_prepare and tx_burst can be called at different stages of a pipeline, on different cores.