On Mon, Nov 13, 2017 at 7:10 PM, Alexander Duyck
<alexander.du...@gmail.com> wrote:
> On Sun, Nov 12, 2017 at 10:16 PM, Or Gerlitz <gerlitz...@gmail.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.
