lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 Jan 2020 11:38:47 +0200 From: Or Gerlitz <gerlitz.or@...il.com> To: Tonghao Zhang <xiangxia.m.yue@...il.com> Cc: Saeed Mahameed <saeedm@....mellanox.co.il>, Roi Dayan <roid@...lanox.com>, Linux Kernel Network Developers <netdev@...r.kernel.org> Subject: Re: mlx5e question about PF fwd packets to PF On Thu, Jan 2, 2020 at 11:32 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote: > On Thu, Jan 2, 2020 at 3:50 PM Or Gerlitz <gerlitz.or@...il.com> wrote: > > On Thu, Jan 2, 2020 at 5:04 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote: > >> On Wed, Jan 1, 2020 at 4:40 AM Or Gerlitz <gerlitz.or@...il.com> wrote: > >> > On Tue, Dec 31, 2019 at 10:39 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote: > I add "skip_sw" option in tc command, and update the tc version to > upstream, it run successfully: > # tc filter add dev $PF0 protocol all parent ffff: prio 1 handle 1 > flower skip_sw action mirred egress redirect dev $PF1 > # tc -d -s filter show dev $PF0 ingress > filter protocol all pref 1 flower chain 0 > filter protocol all pref 1 flower chain 0 handle 0x1 > skip_sw > in_hw in_hw_count 1 As I said, in_hw seems like a bug > action order 1: mirred (Egress Redirect to device enp130s0f1) stolen > index 1 ref 1 bind 1 installed 42 sec used 0 sec > Action statistics: > Sent 408954 bytes 4173 pkt (dropped 0, overlimits 0 requeues 0) > Sent software 0 bytes 0 pkt > Sent hardware 408954 bytes 4173 pkt > backlog 0b 0p requeues 0 > > I don't think so, what is the need? something wrong with N+2 rules as I suggested? > N+2 works fine. good! > I do some research about ovs offload with mellanox nic. cool > I add the uplink of PF0 and PF1 to ovs. and it can offload the > rule(PF0 to PF1, I reproduce with tc commands) to hardware but the nic > can't send the packet out. we don't offload that and should return error on the tc command
Powered by blists - more mailing lists