On Fri, 2016-12-30 at 10:42 +0100, Vincent Bernat wrote: > > I bet the bash authors use that argument when they add another > > feature. In reality all code has a cost. > > The only additional cost is the cost to check if the routing entry is > a blackhole (while the check for anything else already exists). Even > FreeBSD supports this feature since a long time. I wasn't talking about the merits of doing it in any particular place. It was about the same thing being done in multitudes of places - in a different way in each case, with a different API, with different code pulling apart the packet. > The flexibility is also what people like with Linux. True. > hence the need to be able to drop earlier (even adding filters > directly in the NIC). Of course - bypassing the entire stack is always going to be faster. The reason I have the irritates is because I don't bypass it. I use the multiple routing tables, the traffic control engine, iptables, tunnels, bridges, tun/tap, ipsec, veth, vlan's. I tried to collect information on flows - but that slowed throughput to the point people actually noticed it on a 10M bit/sec link. Thus my complaining about having to use a different syntax every time I recognise a packet, how I have to set MARK's to communicate between different levels of the stack. And also thus my long and loud whining about the lack of documentation. It turns out such whining isn't entirely pointless. While looking at the kernel code again I came across the net/openvswitch. Implemented as yet another bolt on, of course. But if it does what it says on the box it may be the answer to my complaints. This quote from the web site is heartening: "The goal with Open vSwitch is to keep the in- kernel code as small as possible (as is necessary for performance)". Indeed.
Attachment:
signature.asc
Description: This is a digitally signed message part