On 07/10/2015 05:43 PM, Stephen Hemminger wrote: > On Fri, 10 Jul 2015 10:32:17 +0100 > Bruce Richardson <bruce.richardson at intel.com> wrote: > >> On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote: >>> From: Stephen Hemminger <shemming at brocade.com> >>> >>> For applications that use m->userdata the initialization can >>> be a signficant (10%) performance penalty. >>> >>> Rather than taking the cache penalty of initializing userdata >>> in the receive handling, do it in the place where mbuf is >>> already cache hot and being setup. >> >> Should the management of the userdata field not be the responsibility of the >> app itself, rather than having the PMD manage it? If the PMD does manage the >> userdata field, I would suggest taking the approach of having the field >> cleared >> by the mbuf library on free, rather than on RX. > > The problem with that is m->userdata is that when the application > gets the mbuf, touching the userdata field causes false cache > sharing and we see a significant performance drop. Internally the > userdata field is only used for few special cases and 0/NULL > is used to indicate that no metadata is present. >
I agree with Bruce: the userdata field is in the second cache line, and we should avoid touching it in rx path. Resetting it in mbuf_free() may not be the solution either: in tx path, the mbufs are freed when we want to send a new mbuf on the hw ring entry, and the mbuf may not be in the cache anymore. I don't understand why doing it in the application induces a performance drop compared to the PMD. What do you mean by false cache sharing?
