[Intel-wired-lan] [next PATCH 1/5] i40e: Introduce devlink interface.

[Alexander Duyck]

On Wed, Aug 10, 2016 at 9:50 AM, John Fastabend
<john.fastabend at gmail.com> wrote:
> On 16-08-10 09:01 AM, Alexander Duyck wrote:
>> On Thu, Aug 4, 2016 at 9:49 AM, Sridhar Samudrala
>> <sridhar.samudrala at intel.com> wrote:
>>> Add initial devlink support to set/get the mode of SRIOV switch.
>>> This patch allows the mode to be set to either 'legacy' or 'switchdev', but
>>> doesn't implement any functionality to create vf representors in switchdev
>>> mode.
>>>
>>> With smode support in iproute2 'devlink' utility, switch mode can be set
>>> and get via following commands.
>>>
>>>     # devlink dev smode pci/0000:05:00.0
>>>     mode: legacy
>>>     # devlink dev set pci/0000:05:00.0 smode switchdev
>>>     # devlink dev smode pci/0000:05:00.0
>>>     mode: switchdev
>>>
>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com>
>>
>> I really don't see much value in this patch.  If you are going to
>> support SwitchDev then just do it.  Otherwise you are adding extra
>> overhead for maintaining two different modes.
>>
>> I would recommend putting this series out to netdev as an RFC.
>> Submitting it to intel-wired-lan is kind of pointless as the audience
>> it to small to get any valuable review.
>>
>> - Alex
>
> I argued at length about this already. Jiri and company wanted this flag
> to push device in and out of this mode. Here we are just following the
> already upstreamed and debated decision.

Yeah, I started doing more research after reviewing this patch.  I see
the idea behind it.  I think the issue if anything is that it seems
like things are a bit backwards.  We probably should be enabling the
SwitchDev bits first and then working on adding devlink knobs to
disable things later.

> This is less about switchdev and more about generating VF netdevs to
> use with ip tools and friends.

Right.  One of the issues I have with this patch set is that it seems
to get things backwards.  They are making VFs appear that don't do
much of anything and then trying to bolt on features after the fact.
We probably need to focus on enabling the VF representation, and then
providing the ability to switch them on and off.  Also I would argue
that we should actually be enabling switch features such as FDB
entries instead of trying to bolt on stuff like flow director which
doesn't really apply to very many switches and isn't as likely to be
used on a switch port.

> Another option would be to just always enable VF netdevs and have no
> legacy mode at all. I think that would be fine it just depends on if
> you think having extra netdevs around will confuse the stack at all.
> It might create a few corner cases but one reasonable thing to do
> would be to just fix those cases as they appear.

I'd say we are better off starting out with them just enabled and then
enabling the option to disable them after the fact.  If we are going
to have this extra code floating around we should be defaulting it to
enabled so that it is more likely to be used.  The legacy option
should only really be there so we can turn this off if we don't want
it.

- Alex