On Fri, Sep 08, 2017 at 06:14:55PM +0800, Hangbin Liu wrote:
> With commit 72b365e8e0fd ("libnetlink: Double the dump buffer size") and
> 460c03f3f3cc ("iplink: double the buffer size also in iplink_get()"), we
> extend the buffer size to avoid truncated message with large numbers of
> VFs. But just as Michal said, this is not future-proof since the NIC
> number is increasing. We have customer even has 220+ VFs now.This sounds like the moment we hit the bigger problem with IFLA_VFINFO_LIST is closer than I thought. The info block for one VF is already 236 bytes long (or was in 4.4) so that 278 VFs would be over the natural limit for IFLA_VFINFO_LIST attribute given by 16-bit nla_len field. > This is not make sense to hard code the buffer and increase it all the time. > So let's just malloc the correct buff size at run time. > > I'm not sure what init size would be suitable, so I keep use the original > size. I have tried with a small size like 1024, and it also works. I don't think it's that important as the command usually runs only for short time so allocating a 32KB buffer even if we could do with less is not a big issue. (I didn't really like the idea of a 32KB buffer on stack but with malloc() it's OK, I would say.) Michal Kubecek
