On 02.11.2016 23:54, Thomas Graf wrote: > On 1 November 2016 at 16:12, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 01.11.2016 21:59, Thomas Graf wrote: >>>> Dumping and verifying which routes get used might actually already be >>>> quite complex on its own. Thus my fear. >>> >>> We even have an API to query which route is used for a tuple. What >>> else would you like to see? >> >> I am not sure here. Some ideas I had were to allow tcpdump (pf_packet) >> sockets sniff at interfaces and also gather and dump the metadata to >> user space (this would depend on bpf programs only doing the >> modifications in metadata and not in the actual packet). > > Not sure I understand. Why does this depend on BPF?
It doesn't. My hope was, if BPF merely tries to modify meta-data, we can provide better debugging tools as if we mangle the packet directly. >> Or maybe just tracing support (without depending on the eBPF program >> developer to have added debugging in the BPF program). > > Absolutely in favour of that. > >>> This will be addressed with signing AFAIK. >> >> This sounds a bit unrealistic. Signing lots of small programs can be a >> huge burden to the entity doing the signing (if it is not on the same >> computer). And as far as I understood the programs should be generated >> dynamically? > > Right, for generated programs, a hash is a better fit and still sufficient. > >>> Would it help if we allow to store the original source used for >>> bytecode generation. What would make it clear which program was used. >> >> I would also be fine with just a strong hash of the bytecode, so the >> program can be identified accurately. Maybe helps with deduplication >> later on, too. ;) > > OK, I think we all already agreed on doing this. > >> Even though I read through the patchset I am not absolutely sure which >> problem it really solves. Especially because lots of things can be done >> already at the ingress vs. egress interface (I looked at patch 4 but I >> am not sure how realistic they are). > > Filtering at egress requires to attach the BPF program to all > potential outgoing interface and then pass every single packet through > the program whereas with LWT BPF, I'm only taking the cost where > actually needed. I do certainly see this point as a big plus. I definitely also thought about this a lot when thinking about how flower can/should be used with multiple interfaces and how to keep its flow tables synchronized. >>> I also don't see how this could possibly scale if all packets must go >>> through a single BPF program. The overhead will be tremendous if you >>> only want to filter a couple of prefixes. >> >> In case of hash table lookup it should be fast. llvm will probably also >> generate jump table for a few 100 ip addresses, no? Additionally the >> routing table lookup could be not done at all. > > Why would I want to accept the overhead if I simply avoid it? Just > parsing the header and doing the hash lookup will add cost, cost for > each packet. That is true, but in case you are outside of the namespace, you still have to calculate the cost of doing the FIB lookup for the BPF program each time, too. E.g. given the lookup cost in a hash for a netnwork namespace pointer vs. the cost of doing a FIB lookup to get a program that does a specific transformation sounds at least in the big O-notiation to be in a better place. ;) If you have to do both anyway, probably your patchset will perform better, I agree. Bye, Hannes
