On Thu, Feb 14, 2019 at 10:34:06AM -0700, David Ahern wrote: > On 2/14/19 6:49 AM, Michal Kubecek wrote: > > On Tue, Feb 12, 2019 at 07:04:17PM -0700, David Ahern wrote: > >> > >> Do we know of any single message sizes > 32k? 2d34851cd341 cites > >> increasing VF's but at some point there is a limit. If not, the whole > >> PEEK thing should go away and we just malloc 32k (or 64k) buffers for > >> each recvmsg. > > > > IFLA_VF_LIST is by far the biggest thing I have seen so far. I don't > > remember exact numbers but the issue with 32KB buffer (for the whole > > RTM_NELINK message) was encountered by some of our customers with NICs > > having 120 or 128 VFs. > > > > There is a bigger issue with IFLA_VFINFO_LIST, though, as it's an > > attribute so that netlink limits its size to 64 KB. IIRC with current > > size of IFLA_VF_INFO this would be reached with 270-280 VFs (I'm sure > > the number was higer than 256 but not too much higher.)
Using netdevsim, 'ip link show' becomes unusable after enabling more than 244 VFs. I guess it depends on how much info per VF is available. > > This would mean unless we let something else grow too much, the whole > > message shouldn't get much bigger than 64 KB. And if we can find some > > other solution (e.g. passing VF information in separate messages if > > client declares support), even 32 KB would be more than enough. > > That's what I was asking, thanks. So 32kB today is sufficient, 64kB has > future buffer. So this whole PEEK and allocate the message size is > overkill. It could just as easily been bumped from 32kB to 64kB in the > original patch and been good for a while. Yes, I think the real problem is how VF-related messages are structured currently. Cheers, Phil
