Message-ID: <43F901BD926A4E43B106BF17856F0755018DC497D4@orsmsx508.amr.corp.intel.com>
Date:	Tue, 26 Apr 2011 09:12:26 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	David Miller <davem@...emloft.net>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"bhutchings@...arflare.com" <bhutchings@...arflare.com>
Subject: RE: [RFC PATCH] netlink: Increase netlink dump skb message size

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Monday, April 25, 2011 11:56 PM
> To: eric.dumazet@...il.com
> Cc: Rose, Gregory V; netdev@...r.kernel.org; bhutchings@...arflare.com
> Subject: Re: [RFC PATCH] netlink: Increase netlink dump skb message size
> 
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Tue, 26 Apr 2011 08:33:17 +0200
> 
> > Le lundi 25 avril 2011 à 15:01 -0700, Greg Rose a écrit :
> >> The message size allocated for rtnl info dumps was limited to a single
> page.
> >> This is not enough for additional interface info available with devices
> >> that support SR-IOV.  Check that the amount of data allocated is
> sufficient
> >> for the amount of data requested.
> >>
> >> Signed-off-by: Greg Rose <gregory.v.rose@...el.com>
> >> ---
> >>
> >>  include/linux/rtnetlink.h |    1 +
> >>  net/core/rtnetlink.c      |    6 ++++++
> >>  net/netlink/af_netlink.c  |   37 +++++++++++++++++++++++++++++++------
> >>  3 files changed, 38 insertions(+), 6 deletions(-)
> >>
> >
> > Hmm, thats a hack, because netlink_dump() is generic and you add
> > something very specific.
> 
> You also can't do this without breaking applications.
> 
> We've trained every single netlink library out there about this message
> size
> formula, so they know that if you allocate at least 8192 bytes for a
> recvmsg()
> call they can receive fully any single netlink message.

I checked the message sizes being generated and they were far less than 8K for 63 VFs and from my calculation would still be less than 8K for 127 VFs as per Ben Hutching's requirements.  I thought I had 16k to work with as that is what is allocated by the iproute2 ip application also as per Ben's prior email.  I checked and that is the case.  But whatever the case I think we're still fine for 8K.  I could put a check in to make sure alloc_size doesn't go over 8k.

> 
> And they must be able to make assumptions like this, otherwise they
> cannot know how to reliably be able to receive a netlink message in
> it's entirety in a generic fashion.
> 
> So one must not attack this problem from this angle.

This was just a bug fix.  If you recall the email thread from last week that brought up this whole thing I was advocating for an entirely new angle myself.  If the bug fix causes more problems than it solves, and that's not rare by any means, then we can toss it and go back to the start.

> 
> It is absolutely necessary to find some way to report the VF
> information, out of band, instead of trying to make the message
> larger.

Absolutely agreed!

> 
> Needing more than 8K to get a dump of a single device over netlink is
> absolutely rediculious, this VF stuff was poorly designed.  If has to
> be fixed and the current stuff marked deprecated.

Again, absolutely no argument from me.

And I have an idea as to how to do this but Ben asked me to come up with a bug fix first and then work on the extensions that would do just what you're saying here later.  I'm fine with dropping the bug fix hack and getting back to my original ideas on the subject.  The problem there is that due to my work load it would be a month or more before I could finish it up and meanwhile the bug still exists.

I'm fine with however you folks want to approach this, just give me some direction.

- 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