netdev - Re: Receive side performance issue with multi-10-GigE and NUMA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Aug 2009 20:14:26 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, David Miller <davem@...emloft.net>,
	fweisbec@...il.com, billfink@...dspring.com,
	netdev@...r.kernel.org, brice@...i.com, gallatin@...i.com
Subject: Re: Receive side performance issue with multi-10-GigE and NUMA

On Wed, Aug 26, 2009 at 07:33:55PM -0400, Steven Rostedt wrote:
> 
> On Wed, 26 Aug 2009, Neil Horman wrote:
> 
> > On Wed, Aug 26, 2009 at 10:40:27PM +0200, Ingo Molnar wrote:
> > > 
> > > * Neil Horman <nhorman@...driver.com> wrote:
> > > 
> > > > On Wed, Aug 26, 2009 at 09:48:35PM +0200, Ingo Molnar wrote:
> > > > > 
> > > > > * David Miller <davem@...emloft.net> wrote:
> > > > > 
> > > > > > From: Ingo Molnar <mingo@...e.hu>
> > > > > > Date: Wed, 26 Aug 2009 21:08:30 +0200
> > > > > > 
> > > > > > > Sigh, no. Please re-read the past discussions about this. 
> > > > > > > trace_skb_sources.c is a hack and should be converted to generic 
> > > > > > > tracepoints. Is there anything in it that cannot be expressed in 
> > > > > > > terms of TRACE_EVENT()?
> > > > > > 
> > > > > > Neil explained why he needed to implement it this way in his reply 
> > > > > > to Steven Rostedt.  I attach it here for your convenience.
> > > > > 
> > > > > thanks. The argument is invalid:
> > > > 
> > > > Just because you assert that doesn't make it so, Ingo.
> > > 
> > > I stand by that statement, the argument is invalid, for the many 
> > > reasons i outlined in my previous mails. (you'd have gotten those 
> > > same arguments had you submitted that patch to the folks who 
> > > maintain kernel/trace/)
> > > 
> 
> > Steven specifically told me to submit the patch to the subsystem maintainer that
> > I'm adding tracepoints for, and the only feedback I got on it was his one
> > question, the answer to which I assume satisfied him, due to that there was no
> > subseuqent discussion.  I'm going to ignore your previous emails, because,
> > despite the various advantages of just using plain TRACE_EVENTs because you
> > provide the ftrace interface, and I found it useful.  Your observation is
> > correct, I like it, and thats what I wanted to use, so I used it.  If you don't
> > want people to use it, don't provide it.
> 
> Actually, I suggested to submit it to the subsystem maintainer if there 
> was no changes to the tracing infrastructure. We may have just had a 
> misunderstanding there. No biggy.
> 
I'm not sure how the addition of an ftrace module constitutes a change to the
tracing infrastructure, but whatever, yes, no biggy.  I've bugun modifying the
TRACE_EVENT that I added to export the data I need directly.  Should be pretty
straightforward.  Dave I'll have a patch up on netdev in a day or two after I
test it.  Steven, should this still just go to netdev with a cc to you?  I'd
like to avoid repeating the same confusion here a second time around if I can

> > 
> > Ok, I'm rather tired of arguing.  Dave, I'll leave this in your hands.  The code
> > I wrote works fairly well in my view, and I feel like the review on it was both
> > positive and sufficent for inclusion.  But thats not my call, its yours.  I can
> > meet my own need with a raw TRACE_EVENT for now just as easily.  IF you feel
> > like the skb plugin should be pulled, please do so, and let me know.  All I ask
> > is that you keep the skb_copy_datagram_iovec TRACE_EVENT in place.  If you pull
> > the ftrace plugin, I'll submit a subsequent patch to agument the printing format
> > so that I can gather the numa allocation and consumption data directly there.
> 
> Yes, please keep the TRACE_EVENT (I think we can all agree on that ;-).
> 
Yes, that is rather centeral to what I'm monitoring :)

> You probably already read my previous email on the matter. Don't delete 
> your plugin patch until we get everything you need with TRACE_EVENT alone.
> 
Its ok, I should have the TRACE_EVENT modified to export this stuff directly by
tomorrow or friday anyway.  I really honestly just liked the ftrace interface
better, I found it a bit less confusing :)

Best
Neil

> Thanks,
> 
> -- Steve
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html