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]
Message-ID: <43F901BD926A4E43B106BF17856F07550145FC7526@orsmsx508.amr.corp.intel.com>
Date:	Thu, 21 Apr 2011 10:02:14 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>
CC:	netdev <netdev@...r.kernel.org>,
	sf-linux-drivers <linux-net-drivers@...arflare.com>
Subject: RE: rtnetlink and many VFs

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Ben Hutchings
> Sent: Thursday, April 21, 2011 7:36 AM
> To: David Miller
> Cc: netdev; sf-linux-drivers
> Subject: rtnetlink and many VFs
> 
> My colleagues have been working on SR-IOV support for sfc.  The hardware
> supports up to 127 VFs per port.
> 
> If we configure all 127 VFs through the net device, an RTM_GETLINK dump
> will need to include messages describing them, with a total size of:
> 
> 127 * (sizeof(struct ifla_vf_mac) + sizeof(struct ifla_vf_vlan) +
>        sizeof(struct ifla_vf_tx_rate) + protocol overhead)
> > 7112
> 
> These messages are nested within the message describing the device as a
> whole, so they cannot be split.  The maximum size of an outgoing netlink
> message, based on NLMSG_GOODSIZE, seems to be min(PAGE_SIZE, 8192).  So
> when PAGE_SIZE = 4096 it is simply impossible to dump information about
> such a device!
> 
> I think it needs to be made possible to grow a netlink skb during
> generation of the first message.  Userspace may still be unable to
> receive the large message but at least it has a chance.

I've been looking at this one too.  The limit seems to be about 40 or so in the most common case.  My netlink fu is weak but I've been looking at the code in iproute2/ip and netlink to see what we can do about it.

As more VFs become possible it really needs a fix.  I was thinking about something along the lines of this:

# ip link show eth(x) vf (n)

Where eth(x) is the physical function that owns the VFs and (n) is the specific VF you want information for.  That way one could easily script something that loops through the VFs and gets the information for each.  This really becomes necessary when we start adding additional MAC and VLAN filters for each VF that need to be displayed.  In that case you can only show a few VFs before you run out of space.

In any case I've been working on an RFC patch for this and hope to have it soon.  I consider this a pretty serious limitation and one could even view it as a bug.

- Greg
Greg Rose
LAD Division
Intel Corp.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ