netdev - Re: [pull request][for-next 00/11] Mellanox, mlx5 E-Switch updates 2017-12-19

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 15:36:41 -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 2:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@...il.com> wrote:
> On Tue, Dec 19, 2017 at 02:39:38PM -0800, Saeed Mahameed wrote:
>> 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.
>
> I was asking only bout Mellanox cards.
>
>>
>> All mlx5 cards do support both ingress and egress ACLs per vport (VF),
>> each has its own namespaces (separate pipeline), hence patch #11.
>
> Alright then.
>
>>
>> So i don't see why you worry so much :).
>
> Oh but because currently they are called like:
>
>                 if (MLX5_CAP_ESW_EGRESS_ACL(dev, ft_support)) {
>                         err = init_egress_acl_root_ns(steering);
> ....
>
>                 if (MLX5_CAP_ESW_INGRESS_ACL(dev, ft_support)) {
>                         err = init_ingress_acl_root_ns(steering);
> ....
>
> and it could cause bigger problems if only one kind were supported,
> like trying to setup egress while it's not supported by the card.
> But again, as it seems both are always supported, that's no issue.
>

Ok, now i see your point, and the driver is already ok for that
matter, even for the extreme non existing cases of when one of the
ACLs is not supported,
ACL users need to query for the ACL namespace before using it, e.g:

root_ns = mlx5_get_flow_vport_acl_namespace(dev,
MLX5_FLOW_NAMESPACE_ESW_EGRESS, vport->vport);
if (!root_ns)
           abort;

so if for some reason  MLX5_CAP_ESW_EGRESS_ACL(dev, ft_support) is
false, then any following call to mlx5_get_flow_vport_acl_namespace
will return NULL, which means "not supported" and those cases are
already handled by the mlx5 eswitch driver.

Saeed.

> Thanks,
> Marcelo
>
>>
>> >   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
>>