[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C5551D9AAB213A418B7FD5E4A6F30A0702F80AEB@ORSMSX106.amr.corp.intel.com>
Date: Mon, 6 Feb 2012 18:36:03 +0000
From: "Rose, Gregory V" <gregory.v.rose@...el.com>
To: Štefan Gula <steweg@...t.sk>
CC: David Miller <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [patch v1, kernel version 3.2.1] rtnetlink workaround around
the skb buff size issue
> -----Original Message-----
> From: steweg@...il.com [mailto:steweg@...il.com] On Behalf Of Štefan Gula
> Sent: Monday, February 06, 2012 10:32 AM
> To: Rose, Gregory V
> Cc: David Miller; linux-kernel@...r.kernel.org; netdev@...r.kernel.org
> Subject: Re: [patch v1, kernel version 3.2.1] rtnetlink workaround around
> the skb buff size issue
>
> 2012/2/6 Rose, Gregory V <gregory.v.rose@...el.com>:
> > That is exactly my approach. We currently have a *bug* in the kernel
> that this patch is addressing. The kernel is attempting to provide too
> much information for the netlink interface to handle and it's breaking
> things. So what I want to do is fix the immediate problem while still
> providing a way for folks to get the information they need. I've
> accomplished this by doing exactly what Dave asked me to do, provide a
> filter that defaults to off and then provide a way for the user to request
> discrete chunks of information in the dump that won't exceed the netlink
> buffer limits.
> >
> > The patch is fairly unobtrusive and simple to understand.
> >
> > I appreciate that it doesn't do all that you'd like to see done and I
> see no reason why you couldn't go on and develop the extended features
> that you would like to see, correct? There's nothing in my patch that
> would prevent that so far as I can tell, although I'm not that familiar
> with your requirements or proposals yet.
> Greg, your patch is completely ok for filtering. I like that thing. I
> am just stating that it doesn't eliminate every possible option that
> can happen so I believe we should also have method for using cycles -
> that's what my patch is doing. So I believe both approaches should be
> applied.
OK, good deal. I'll go ahead and finish up my kernel patch and the associated iproute2 patch.
Thanks,
- Greg
--
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
Powered by blists - more mailing lists