Re: [net v1] fib_rules: interface group matching
❦ 14 septembre 2016 17:25 CEST, David Ahern : >> I could just give more time to VRF. I also had some concerns over >> performance with the way Netfilter integration is done, but I understand >> that I could just stay away from POSTROUTING rules which is the only >> hook executed twice? > With the changes that were committed this past weekend, the VRF code > is now setup where I can set a flag on a per VRF basis to disable the > extra rx and tx processing - ie., no network taps, no netfilter, no > qdisc, etc. Drops the overhead of VRF to ~3% maybe a bit less. I need > to think about the user api a bit more and formalize the patch. Given > my other commitments that probably won't happen until mid-October. But > in terms of a building block, the overhead of VRF is continuing to > drop. Fine by me. We can drop my patch. Thanks! -- Program defensively. - The Elements of Programming Style (Kernighan & Plauger)
Re: [net v1] fib_rules: interface group matching
On 9/14/16 9:14 AM, Vincent Bernat wrote: > I could just give more time to VRF. I also had some concerns over > performance with the way Netfilter integration is done, but I understand > that I could just stay away from POSTROUTING rules which is the only > hook executed twice? > With the changes that were committed this past weekend, the VRF code is now setup where I can set a flag on a per VRF basis to disable the extra rx and tx processing - ie., no network taps, no netfilter, no qdisc, etc. Drops the overhead of VRF to ~3% maybe a bit less. I need to think about the user api a bit more and formalize the patch. Given my other commitments that probably won't happen until mid-October. But in terms of a building block, the overhead of VRF is continuing to drop.
Re: [net v1] fib_rules: interface group matching
❦ 14 septembre 2016 16:39 CEST, David Ahern : When a user wants to assign a routing table to a group of incoming interfaces, the current solutions are: - one IP rule for each interface (scalability problems) - use of fwmark and devgroup matcher (don't work with internal route lookups, used for example by RPF) - use of VRF devices (more complex) >>> >>> Why do you believe that? A VRF is a formalized grouping of interfaces >>> that includes an API for locally generated traffic to specify which >>> VRF/group to use. And, with the l3mdev rule you only need 1 rule for >>> all VRFs regardless of the number which is the best solution to the >>> scalability problem of adding rules per device/group/VRF. >>> >>> What use case are trying to solve? >> >> Local processes have to be made aware of the VRF by binding to the >> pseudo-device. Some processes may be tricked by LD_PRELOAD but some >> won't (like stuff written in Go). Maybe I should just find a better way >> to bind a process to a VRF without its cooperation. > > What API are you using for interface groups? How does an app tell the > kernel to use interface group 1 versus group 2? In my testbed, I have only one local application which is dnsmasq as a DHCP server. It sends back the answer to the physical interface (with sendmsg() and auxillary data). So it makes my argument a bit moot as the situation is in fact worse without VRF. :-/ My testbed is here (with use of VRF, more recent commits just use plain ip rules): https://github.com/vincentbernat/network-lab/blob/d86e9ed658863ef0f51d7b853d0dc9f8b7427b21/lab-l3-hyperv/setup I could just give more time to VRF. I also had some concerns over performance with the way Netfilter integration is done, but I understand that I could just stay away from POSTROUTING rules which is the only hook executed twice? -- All things that are, are with more spirit chased than enjoyed. -- Shakespeare, "Merchant of Venice"
Re: [net v1] fib_rules: interface group matching
On 9/14/16 8:25 AM, Vincent Bernat wrote: > ❦ 14 septembre 2016 16:15 CEST, David Ahern : > >>> When a user wants to assign a routing table to a group of incoming >>> interfaces, the current solutions are: >>> >>> - one IP rule for each interface (scalability problems) >>> - use of fwmark and devgroup matcher (don't work with internal route >>>lookups, used for example by RPF) >>> - use of VRF devices (more complex) >> >> Why do you believe that? A VRF is a formalized grouping of interfaces >> that includes an API for locally generated traffic to specify which >> VRF/group to use. And, with the l3mdev rule you only need 1 rule for >> all VRFs regardless of the number which is the best solution to the >> scalability problem of adding rules per device/group/VRF. >> >> What use case are trying to solve? > > Local processes have to be made aware of the VRF by binding to the > pseudo-device. Some processes may be tricked by LD_PRELOAD but some > won't (like stuff written in Go). Maybe I should just find a better way > to bind a process to a VRF without its cooperation. > What API are you using for interface groups? How does an app tell the kernel to use interface group 1 versus group 2? LD_PRELOAD and overloading socket is an ad-hoc hack at best with many holes - as you have found. We (Cumulus Linux) are using this cgroups patch: http://www.mail-archive.com/netdev@vger.kernel.org/msg93408.html I want something formal like the cgroups patch or even the first idea of adding a default sk_bound_dev_if to the task struct: https://github.com/dsahern/linux/commit/b3e5ccc291505c8a503edb20ea2c2b5e86bed96f Parent-to-child inheritance of the setting is a requirement as is the setting getting applied to all IPv4/v6 sockets without action by the process itself. Still have some work to do to get a solution into the kernel.
Re: [net v1] fib_rules: interface group matching
❦ 14 septembre 2016 16:15 CEST, David Ahern : >> When a user wants to assign a routing table to a group of incoming >> interfaces, the current solutions are: >> >> - one IP rule for each interface (scalability problems) >> - use of fwmark and devgroup matcher (don't work with internal route >>lookups, used for example by RPF) >> - use of VRF devices (more complex) > > Why do you believe that? A VRF is a formalized grouping of interfaces > that includes an API for locally generated traffic to specify which > VRF/group to use. And, with the l3mdev rule you only need 1 rule for > all VRFs regardless of the number which is the best solution to the > scalability problem of adding rules per device/group/VRF. > > What use case are trying to solve? Local processes have to be made aware of the VRF by binding to the pseudo-device. Some processes may be tricked by LD_PRELOAD but some won't (like stuff written in Go). Maybe I should just find a better way to bind a process to a VRF without its cooperation. -- Instrument your programs. Measure before making "efficiency" changes. - The Elements of Programming Style (Kernighan & Plauger)
Re: [net v1] fib_rules: interface group matching
On 9/14/16 6:40 AM, Vincent Bernat wrote: > When a user wants to assign a routing table to a group of incoming > interfaces, the current solutions are: > > - one IP rule for each interface (scalability problems) > - use of fwmark and devgroup matcher (don't work with internal route >lookups, used for example by RPF) > - use of VRF devices (more complex) Why do you believe that? A VRF is a formalized grouping of interfaces that includes an API for locally generated traffic to specify which VRF/group to use. And, with the l3mdev rule you only need 1 rule for all VRFs regardless of the number which is the best solution to the scalability problem of adding rules per device/group/VRF. What use case are trying to solve?
Re: [net v1] fib_rules: interface group matching
❦ 14 septembre 2016 14:40 CEST, Vincent Bernat : > Each interface can be assigned to a numeric group using IFLA_GROUP. This > commit enables a user to reference such a group into an IP rule. Here is > an example of output of iproute2: > > $ ip rule show > 0: from all lookup local > 32764: from all iifgroup 2 lookup 2 > 32765: from all iifgroup 1 lookup 1 > 32766: from all lookup main > 32767: from all lookup default The patch for iproute2 is available here (didn't post it inline to avoid confuse patchwork): http://paste.debian.net/821247/ -- Say what you mean, simply and directly. - The Elements of Programming Style (Kernighan & Plauger)