netdev - Re: [PATCH net-next 2/4] net: add IPv4 routing FIB support for switchdev

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:	Mon, 2 Mar 2015 14:28:55 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	Netdev <netdev@...r.kernel.org>,
	Jiří Pírko <jiri@...nulli.us>,
	Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net-next 2/4] net: add IPv4 routing FIB support for switchdev

On Mon, Mar 2, 2015 at 10:20 AM, David Miller <davem@...emloft.net> wrote:
> From: sfeldma@...il.com
> Date: Mon,  2 Mar 2015 01:29:13 -0800
>
>> +     dev = netdev_switch_get_by_fib_dev(fi->fib_dev);
>  ...
>> +     dev = netdev_switch_get_by_fib_dev(fi->fib_dev);
>
> I really should get rid of the fib_dev define, it's always trouble.
>
> Routes can have multiple next hops, and when that is the case you
> cannot offload them to hardware in your initial implementation here.
>
> Next hops need to be iterated upon, and that currently can't be
> modelled with your abstration right now.

This gets into the issue of how to solve the case of a route with
nexthops devs not belonging to the same offload device.  So I think
you're right, and probably what we should do in the model for a first
pass is scan all the route's nh devs and make sure the devs have the
same switch_id before calling into the driver.  We have everything to
do this; I think I was punting on ECMP for this first pass to get
something out for L3, even if it was single-path.

I can revisit this for v3, but keep rocker single-path, or I can do
all for v3 and add the ECMP support to rocker.  I'm inclined to do the
former, so we can take this one step at a time.

> I also don't see you testing properly for
> net->ipv4.fib_has_custom_rules,
>
> Oh, I see, that happens in patch #4.  Please make that logic present
> from the very beginning.

Ok, I'll shuffle things around for v3.

> If you see a multi-nexthop route, for this initial implementation,
> you will need to uninstall all routes from the hardware.

I don't follow that?  In this initial implementation, rocker rejects
ECMP routes, returning -EOPNTOSUPP, but the route is still installed
in the kernel.  I'm not seeing why we'd need to uninstall from hw all
the single-path routes.

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