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: Wed, 13 Nov 2019 14:06:51 +0100 From: Jiri Pirko <jiri@...nulli.us> To: Jakub Kicinski <jakub.kicinski@...ronome.com> Cc: Saeed Mahameed <saeedm@...lanox.com>, "David S. Miller" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Ariel Levkovich <lariel@...lanox.com> Subject: Re: [net-next 8/8] net/mlx5: Add vf ACL access via tc flower Wed, Nov 13, 2019 at 12:41:24AM CET, jakub.kicinski@...ronome.com wrote: >On Tue, 12 Nov 2019 17:13:53 +0000, Saeed Mahameed wrote: >> From: Ariel Levkovich <lariel@...lanox.com> >> >> Implementing vf ACL access via tc flower api to allow >> admins configure the allowed vlan ids on a vf interface. >> >> To add a vlan id to a vf's ingress/egress ACL table while >> in legacy sriov mode, the implementation intercepts tc flows >> created on the pf device where the flower matching keys include >> the vf's mac address as the src_mac (eswitch ingress) or the >> dst_mac (eswitch egress) while the action is accept. >> >> In such cases, the mlx5 driver interpets these flows as adding >> a vlan id to the vf's ingress/egress ACL table and updates >> the rules in that table using eswitch ACL configuration api >> that is introduced in a previous patch. > >Nack, the magic interpretation of rules installed on the PF is a no go. For the record, I don't like this approach either. The solution is out there, one just have to properly implement bridge offloading.
Powered by blists - more mailing lists