-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Eric Dumazet
Sent: Wednesday, April 27, 2011 9:30 AM
To: Steve Hodgson
Cc: Rose, Gregory V; David Miller; netdev@vger.kernel.org;
bhutchings@solarflare.com
Subject: Re: [RFC PATCH] netlink: Increase netlink dump skb message size

Le mercredi 27 avril 2011 à 16:46 +0100, Steve Hodgson a écrit :

quoted

On 04/27/2011 04:24 PM, Eric Dumazet wrote:

quoted

Le mardi 26 avril 2011 à 09:12 -0700, Rose, Gregory V a écrit :

quoted

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

some direction.

quoted

quoted

I would just try following patch :

This allows the sfc driver to use 102 VFs, up from the current limit of
45 VFs.

It's unfortunate that this patch isn't sufficient to allow all 127 VFs
to be used, but whilst we wait for a new netlink api this is an
improvement worth having.

netlink recvmsg() supports MSG_PEEK so user would get the needed size of
its buffer before calling the real recvmsg()

big blobs could be attached as skb fragments (up to 64Kbytes), but do we
really want this...

[Greg Rose] 

I'm looking into an approach in which we make the get info dump for VFs orthogonal to the set VF info, i.e. like this:

To set VF info we would follow the current convention:

# ip link set eth(x) vf (n) mac xx:xx:xx:xx:xx:xx
# ip link set eth(x) vf (n) vlan (nnnn)

To see VF info:

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

would show that VF's mac and vlan and could then be expanded in the future to display more information required for additional features that users are asking for.

The IFLA_VF_INFO dump would be moved out of the info dump for the physical function interface and would no longer be nested which would get rid of the need for huge amounts of buffer for info dumps on VFs.  The ip link show command for the PF would need to report the number of VFs currently allocated to the PF so that could fed into a script that loops to show each VFs info.

I think this approach would fix the problems we're looking at right now.

- Greg