[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALzJLG8EqGLw66bzBdor629mvJdcN+YOAesTxW8_QYt_teUMiA@mail.gmail.com>
Date: Tue, 29 Aug 2017 13:13:09 +0300
From: Saeed Mahameed <saeedm@....mellanox.co.il>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: Saeed Mahameed <saeedm@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
Eugenia Emantayev <eugenia@...lanox.com>,
Mohamad Haj Yahia <mohamad@...lanox.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: [PATCH net-next 1/4] net: Add SRIOV VGT+ support
On Mon, Aug 28, 2017 at 6:52 PM, Sabrina Dubroca <sd@...asysnail.net> wrote:
> 2017-08-27, 14:06:15 +0300, Saeed Mahameed wrote:
> [...]
>> +#define VF_VLAN_BITMAP DIV_ROUND_UP(VF_VLAN_N_VID, sizeof(__u64) * BITS_PER_BYTE)
>> +struct ifla_vf_vlan_trunk {
>> + __u32 vf;
>> + __u64 allowed_vlans_8021q_bm[VF_VLAN_BITMAP];
>> + __u64 allowed_vlans_8021ad_bm[VF_VLAN_BITMAP];
>> +};
>
> This is huge (1032B). And you put one of these in the netlink message
> for each VF. This means that with 51 VF (at least in my environment,
> where each VF takes 1296B), you're going to overflow the u16 size of a
> single attribute (IFLA_VFINFO_LIST), and you cannot dump the device
> anymore. I'm afraid this is going to break existing setups.
>
Yes ! We will fix this,
we are considering to report only a boolean in VFINFO which indecates
if VGT+ is enable or not
and provide a new attribute per VF to report only the vlan list of specific VF.
Thanks for the input,
we will handle this.
> --
> Sabrina
Powered by blists - more mailing lists