netdev - RE: [PATCH net-next 1/3] net: add IPv4 routing FIB support for swdev

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:	Wed, 7 Jan 2015 09:54:30 -0800
From:	Shrijeet Mukherjee <shm@...ulusnetworks.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Scott Feldman <sfeldma@...il.com>, Netdev <netdev@...r.kernel.org>,
	Jiří Pírko <jiri@...nulli.us>,
	john fastabend <john.fastabend@...il.com>,
	Thomas Graf <tgraf@...g.ch>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: RE: [PATCH net-next 1/3] net: add IPv4 routing FIB support for swdev

>
>I could come up with several ways how to model hardware. Depending on that
>the integration with rules is easy or nearly impossible:
>
>1) it simply cannot deal with ip rules, so there is no way an ACL can
>influence the
>outcome of a routing table lookup - if the feature should be used, it has
>to use
>the slow-path in the kernel.

As Scott was saying, most hardware has table id's and the ability to
identify and prioritize that way.


>
>2) ACLs can influence which routing table will get queried - this sounds
>very much
>like the ip rule model and it seems not too hard to model that.

This clearly can be made to work .. the problem is really the space of
policy routing (i.e jump across VRF's incase of a lookup failure) when
combined with the space of ip rule flexibility.


>
>3) Routing implementations in the hardware have a single routing table and
>the
>leafs carry different actions with priorities: making this kind of model
>working
>with the ip rule concept will become very difficult and it might require
>lots of
>algorithmic code by every driver to adapt to a single API provided by
>Linux. It
>might be possible, if the hardware provides actions like backtrack and
>retrack and
>can keep state of priorities during walking the tree, I really doubt that.


In the short term .. this maybe a good way to go but with a simplication.
Some tables are offloaded and the rest at the full table level is in
software. Finally then you can put a "default route" in the hardware table
to punt to cpu and then keep the software model clever and the hardware
model fast ?

>
>Implementations of type 3) would look naturally to do in hardware (see
>different
>Cisco policy routing configurations or ipv6 subtree feature), so it seems
>it won't
>be possible to find a simple way to fuse rules and offloading in case of
>point 3).
>
>Rocker sounds a lot like model 2) and this seems possible and should be a
>matter
>of API design. It should merely be a matter of nicely model the data
>structures. ;)
>
>Also, @Scott: if you build drivers with l3 offloading as modules, don't you
>need to
>push the full routing tables to the hw once? Maybe we should think about
>the
>drivers pulling routing information from the kernel, the kernel only
>notifying
>something changed?
>
>Bye,
>Hannes
>
--
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