[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMDZJNWrg_q9p8Av-xWwiCRte4XBn3Nd66EXh8EXpQG2gB0-=A@mail.gmail.com>
Date: Fri, 22 Feb 2019 15:48:25 +0800
From: Tonghao Zhang <xiangxia.m.yue@...il.com>
To: Or Gerlitz <gerlitz.or@...il.com>
Cc: Saeed Mahameed <saeedm@...lanox.com>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when
decapsulation offload not supported
On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@...il.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@...il.com> wrote:
> >
> > From: Tonghao Zhang <xiangxia.m.yue@...il.com>
> >
> > If we try to offload decapsulation actions to VFs hw, we get the log [1].
>
> but the switching was on the tunnel type (if (tunnel_type == [...]) -
Yes, but we try to offload tc flow to VF device. For example
the p2p1_0 is VF, but not rep
tc qdisc add dev p2p1_0 ingress
ethtool -K p2p1_0 hw-tc-offload on
tc filter add dev p2p1_0 protocol ip chain 0 parent ffff: prio 1
flower skip_sw dst_mac 00:10:56:fb:64:e8 dst_ip 10.100.3.104 src_ip
10.100.4.0/24 enc_dst_ip 192.168.240.128 enc_key_id 100 enc_dst_port
4789 action tunnel_key unset
> what rules caused you to get here?
> what was the ingress device and what was the egress (mirred) device?
the ingress device is p2p1_0 (VF), and the egress (mirred) device is not used
>
> > It's not friendly, because the kind of net device is null, and we don't
> > know what '0' means.
> >
> > [1] "mlx5_core 0000:05:01.2 vf_0: decapsulation offload is not supported for net device (0)"
Powered by blists - more mailing lists