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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 Dec 2017 14:39:38 -0800
From:   Saeed Mahameed <saeedm@....mellanox.co.il>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     Saeed Mahameed <saeedm@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Doug Ledford <dledford@...hat.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        linux-rdma@...r.kernel.org, Leon Romanovsky <leonro@...lanox.com>
Subject: Re: [pull request][for-next 00/11] Mellanox, mlx5 E-Switch updates 2017-12-19

On Tue, Dec 19, 2017 at 1:54 PM, Marcelo Ricardo Leitner
<marcelo.leitner@...il.com> wrote:
> On Tue, Dec 19, 2017 at 12:33:29PM -0800, Saeed Mahameed wrote:
>> Hi Dave and Doug,
>>
>> ==============
>> This series includes updates for mlx5 E-Switch infrastructures,
>> to be merged into net-next and rdma-next trees.
>>
>> Mark's patches provide E-Switch refactoring that generalize the mlx5
>> E-Switch vf representors interfaces and data structures. The serious is
>> mainly focused on moving ethernet (netdev) specific representors logic out
>> of E-Switch (eswitch.c) into mlx5e representor module (en_rep.c), which
>> provides better separation and allows future support for other types of vf
>> representors (e.g. RDMA).
>>
>> Gal's patches at the end of this serious, provide a simple syntax fix and
>> two other patches that handles vport ingress/egress ACL steering name
>> spaces to be aligned with the Firmware/Hardware specs.
>
> Patch 10 actually looks quite worrysome if a card would support only
> one ingress or egress, but if all of them support both, then it should
> be fine yes. Is that possible, to support only one direction?
>

Hi Marcelo,

Patch 10 is a function renaming patch that fixes a function name to
correspond with its behavior!

Are you asking about all mlx5 cards or all cards in general ?
All patches in this series, and specifically patches 10,11 only
concern mlx5 eswitch specific implementation and mlx5 hardware spec,
they have nothing to do with other vendors cards.

All mlx5 cards do support both ingress and egress ACLs per vport (VF),
each has its own namespaces (separate pipeline), hence patch #11.

So i don't see why you worry so much :).

>   Marcelo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ