On Sun, 1 Nov 2015 06:45:31 +0200 Arnon Warshavsky <arnon at qwilt.com> wrote:
> My 2 cents, > > This was brought up in the recent user space summit, and it seems that > indeed there is no one cache lines arrangement that fits all. > OTOH multiple compile time options to suffice all flavors, would make it > unpleasant to read maintain test and debug. > (I think there was quiet a consensus in favor of reducing compile options > in general) > > Currently I manage similar deviations via our own source control which I > admit to be quite a pain. > I would prefer an option of code manipulation/generation by some script > during dpdk install, > which takes the default version of rte_mbuf.h, > along with an optional user file (json,xml,elvish,whatever) defining the > structure replacements, > creating your custom version, and placing it instead of the installed copy > of rte_mbuf.h. > Maybe the only facility required from dpdk is just the ability to register > calls to such user scripts at some install stage(s), providing the mean > along with responsibility to the user. > > /Arnon > > > > On Sat, Oct 31, 2015 at 6:44 AM, shesha Sreenivasamurthy (shesha) < > shesha at cisco.com> wrote: > > > In Cisco, we are using DPDK for a very high speed packet processor > > application. We don't use NIC TCP offload / RSS hashing. Putting those > > fields in the first cache-line - and the obligatory mb->next datum in the > > second cache line - causes significant LSU pressure and performance > > degradation. If it does not affect other applications, I would like to > > propose reshuffling of fields so that the obligator "next" field falls in > > first cache line and RSS hashing goes to next. If this re-shuffling indeed > > hurts other applications, another idea is to make it compile time > > configurable. Please provide feedback. > > > > -- > > - Thanks > > char * (*shesha) (uint64_t cache, uint8_t F00D) > > { return 0x0000C0DE; } > > Having different layouts will be a disaster for distro's they have to choose one. And I hate to introduce more configuration! But we see the same issue. It would make sense if there were configuration options for some common optimizations NO_TX_OFFLOAD, NO_MULTISEG, NO_REFCOUNT and then the mbuf got optimized for those combinations. Seems better than config options like LAYOUT1, LAYOUT2, ... In this specific case, I think lots of driver could be check nb_segs == 1 and avoiding the next field for simple packets. Long term, I think this will be losing battle. As DPDK grows more features, the current mbuf structure will grow there is really nothing stopping the bloat of meta data.