[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d007a9e-5c00-e4e4-4908-0922427986f5@mellanox.com>
Date: Tue, 21 Jan 2020 09:53:36 +0000
From: Roi Dayan <roid@...lanox.com>
To: Or Gerlitz <gerlitz.or@...il.com>
CC: "xiangxia.m.yue@...il.com" <xiangxia.m.yue@...il.com>,
"saeedm@....mellanox.co.il" <saeedm@....mellanox.co.il>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net/mlx5e: Don't allow forwarding between
uplink
On 2020-01-21 11:49 AM, Or Gerlitz wrote:
> On Tue, Jan 21, 2020 at 11:39 AM Roi Dayan <roid@...lanox.com> wrote:
>> On 2020-01-19 4:25 AM, xiangxia.m.yue@...il.com wrote:
>
>> I noticed you still modified mlx5e_is_valid_eswitch_fwd_dev() which
>> is called from parse tc actions and also from resolving route for vxlan rules.
>>
>> I tested the patch for normal, lag and ecmp modes.
>> ecmp vxlan encap rule breaks now as not supported.
>> the break is in get_route_and_out_devs() at this part
>>
>> else if (mlx5e_eswitch_rep(dev) &&
>> mlx5e_is_valid_eswitch_fwd_dev(priv, dev))
>>
>> since ecmp is like lag we fail on the same scenario here that
>> we test uplink priv but not input vport.
>
> Guys,
>
> I thought we agreed to hold on with blocking this in the driver -
> should 1st see that the FW is fixed.
>
the internal ticket is enough for tracking.
as long as fw is not fixed we have an issue the rule is not working
properly so this fix is actually more needed now as we add a rule
to fw that actually blocks requested traffic.
Powered by blists - more mailing lists