[net-next,8/8] net/mlx5e: Support adding ingress tc rule when egress device flag is set

When ndo_setup_tc is called with an egress_dev flag set, it means that
the ndo call was executed on the mirred action (egress) device and not
on the ingress device.

In order to support this kind of ndo_setup_tc call, and insert the
correct decap rule to the hardware, the uplink device on the same eswitch
should be found.

Currently, we use this resolution between the mirred device and the
uplink on the same eswitch to offload vxlan shared device decap rules.

Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++++++++
 1 file changed, 8 insertions(+)

On 16-11-30 06:41 AM, Hadar Hen Zion wrote:
> When ndo_setup_tc is called with an egress_dev flag set, it means that
> the ndo call was executed on the mirred action (egress) device and not
> on the ingress device.
> 
> In order to support this kind of ndo_setup_tc call, and insert the
> correct decap rule to the hardware, the uplink device on the same eswitch
> should be found.
> 
> Currently, we use this resolution between the mirred device and the
> uplink on the same eswitch to offload vxlan shared device decap rules.
> 
> Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
> ---

Hi Hadar,

I started to dig through these patches and the last series here,

   Re: [PATCH net-next 00/13] Mellanox 100G SRIOV offloads tunnel_key
set/release

Can you explain how these two are related? I'm guessing in that first
series the actual redirect action to a tunnel device was being ignore?

Does this series clean up that bit of software/hardware alignment.

Thanks,
John


>  drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> index 0868677..8503788 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> @@ -289,6 +289,14 @@ static int mlx5e_rep_ndo_setup_tc(struct net_device *dev, u32 handle,
>  	if (TC_H_MAJ(handle) != TC_H_MAJ(TC_H_INGRESS))
>  		return -EOPNOTSUPP;
>  
> +	if (tc->egress_dev) {
> +		struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
> +		struct net_device *uplink_dev = mlx5_eswitch_get_uplink_netdev(esw);
> +
> +		return uplink_dev->netdev_ops->ndo_setup_tc(uplink_dev, handle,
> +							    proto, tc);
> +	}
> +
>  	switch (tc->type) {
>  	case TC_SETUP_CLSFLOWER:
>  		switch (tc->cls_flower->command) {
>

On Wed, Nov 30, 2016 at 6:36 PM, John Fastabend
<john.fastabend@gmail.com> wrote:

> I started to dig through these patches and the last series here,
>
>    Re: [PATCH net-next 00/13] Mellanox 100G SRIOV offloads tunnel_key
> set/release

> Can you explain how these two are related? I'm guessing in that first
> series the actual redirect action to a tunnel device was being ignore?

> Does this series clean up that bit of software/hardware alignment.

If only the 1st series is applied, the kernel pieces are functional
but with user-space
manually putting the decap (tunnel key release) TC rule on the uplink device
(tc tool -> UAPI --> tc core --> flower --> mlx5), but under real life
use-case, the rule
is put on shared-tunnel device, so this series adds on the prev one.

Or.