Thread (6 messages) 6 messages, 4 authors, 2012-01-30

RE: Regression: "rtnetlink: Compute and store minimum ifinfo dump size" breaks glibc's getifaddrs()

From: Rose, Gregory V <hidden>
Date: 2012-01-30 17:03:45

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Monday, January 30, 2012 8:58 AM
To: Rose, Gregory V
Cc: david.vrabel@citrix.com; netdev@vger.kernel.org; steweg@gmail.com
Subject: Re: Regression: "rtnetlink: Compute and store minimum ifinfo dump
size" breaks glibc's getifaddrs()

From: "Rose, Gregory V" <redacted>
Date: Mon, 30 Jan 2012 16:50:58 +0000
quoted
Maybe we should have 'ip link show' just display the number of VFs
and then have a new 'ip' tool syntax along the lines of 'ip link
show eth(x) vf (n)' where eth(x) is the PF and n is the number of
the VF.  Then it could show all relevant information for just that
VF.  Scripts could parse the number of VFs from the first call to
'ip link show' and then loop to show the details of each VF.

Just an idea... maybe there are other ones out there but it's just
getting ridiculous how much data has to be transferred back and
forth during the basic 'ip link show' command when the interface as
subordinate VFs now that we're getting to devices with up to 256
VFs.
The fix is almost certainly that we need to require that the application
turn on the publishing of features it is interested in.

The inet_diag sockets do something like this, wherein you set bits in
some flags of the request saying what attributes you want to see.

It seems clear that we must, at this point, turn off VF attributes by
default.

Could you do some work on this?  If you don't have the time I'll look
into it, because we'll need to backport this to -stable too.
Yeah, I can push out some other things I'm working on to get on this.

- Greg
Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help