Message-ID: <CAJ3xEMj5KLRCfQto+Mc1U=wo=u8coRZm-VW2R4AKMRbMGYo1SA@mail.gmail.com>
Date:   Tue, 14 Nov 2017 18:44:48 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Andy Gospodarek <gospo@...adcom.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        John Fastabend <john.fastabend@...il.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: SRIOV switchdev mode BoF minutes

On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>> On Sun, Nov 12, 2017 at 10:38 PM, Alexander Duyck

>> The what we call slow path requirements are the following:
>>
>> 1. xmit on VF rep always turns to a receive on the VF, regardless of
>> the offloaded SW steering rules ("send-to-vport")
>>
>> 2. xmit on VF which doesn't meet any offloaded SW steering rules must
>> be received into the host OS from the VF rep

>> 1,2 above must hold also for the uplink and the PF reps

> I am well aware of the requirements. We discussed these with Jiri at
> the previous netdev.

>> When the i40e limitation was described to @ netdev, it seems you have a problem
>> with VF xmit that should be turned to be a recv on the VF rep but also
>> goes to the wire.

>> It smells as if a FW patch can solve that, isn't that?

> That is a huge maybe. We looked into it last time and while we can
> meet requirements 1 and 2 we do so with a heavy performance penalty
> due to the fact that we don't support anywhere near the same number of
> flows as a true switch. Also while that might work for i40e

to recap on i40e, you can support the slow path requirements, but  you have an
issue with the fast path (== offloaded flows)? what is the issue there?

> we still have a much larger install base of ixgbe ports that we have to support.

ok, but support is one thing and keep enhancing a ten years old wrong
SW model is 2nd thing

>>>> I would have to disagree with this. For devices such as 82599 that
>>> doesn't have a true switch this may limit future functionality since
>>> we can't move it over to switchdev mode. For example one thing I may
>>> need to add is the ability to disable multicast and broadcast receive
>>> on a per-VF basis at some point in the future.

>> We are on the same boat with ConnectX3/mlx4, so us lucky that misery loves
>> company (my google search also yielded "many narrow-half consolation" is that
>> completely unrelated?) - the legacy mode for ixgbe/mlx4 is there for ~8-10 years
>> - and since then both companies had 2-3 newer HW generations. I don't see why
>> you can't come to your customers and tell that newish functionality needs newer
>> HW - it will also help sell more from the new stuff..  If you keep
>> extending the legacy mode, more ppl/drivers will do that as well and it will not let us go
>> in the right direction.

> Well I don't know about you guys, but we still are selling parts
> supported by ixgbe

Same here, we are selling lots of CX3 and have to support that, but I didn't
see why someone will want new features there.

> still been adding new hardware as recently as just a couple years ago.

wait, that's different story.

You are saying that your older HW doesn't support e-switch
and you want to keep doing new parts of that older HW and you want the
kernel to keep enhance a wrong SW model b/c you are doing new parts
from old HW, I don't see why we as a community need to go there.

Lets focus on this point for a moment before discussing the other points
you raised.

Or.

Powered by blists - more mailing lists