On Mon, Mar 18, 2013 at 9:41 PM, Andre Oppermann <an...@freebsd.org> wrote: > On 18.03.2013 13:20, Alexander V. Chernikov wrote: >> >> On 17.03.2013, at 23:54, Andre Oppermann <an...@freebsd.org> wrote: >> >>> On 17.03.2013 19:57, Alexander V. Chernikov wrote: >>>> >>>> On 17.03.2013 13:20, Sami Halabi wrote: >>>>>> >>>>>> ITOH OpenBSD has a complete implementation of MPLS out of the box, >>>>>> maybe >>>> >>>> Their control plane code is mostly useless due to design approach >>>> (routing daemons talk via kernel). >>> >>> >>> What's your approach? >> >> It is actually not mine. We have discussed this a bit in radix-related >> thread. Generally quagga/bird (and other hiperf hardware-accelerated and >> software routers) have feature-rich RIb from which best routes (possibly >> multipath) are installed to kernel/fib. Kernel main task should be to do >> efficient lookups while every other advanced feature should be implemented >> in userland. > > > Yes, we have started discussing it but haven't reached a conclusion among > the > two philosophies. We have also agreed that the current radix code is > horrible > in terms of cache misses per lookup. That however doesn't preclude an > agnostic > FIB+RIB approach. It's mostly a matter of structure layout to keep it > efficient. > > >>>> Their data plane code, well.. Yes, we can use some defines from their >>>> headers, but that's all :) >>>>>> >>>>>> porting it would be short and more straight forward than porting linux >>>>>> LDP >>>>>> implementation of BIRD. >>>> >>>> >>>> It is not 'linux' implementation. LDP itself is cross-platform. >>>> The most tricky place here is control plane. >>>> However, making _fast_ MPLS switching is tricky too, since it requires >>>> chages in our netisr/ethernet >>>> handling code. >>> >>> >>> Can you explain what changes you think are necessary and why? > >> >> >> We definitely need ability to dispatch chain of mbufs - this was already >> discussed in intel rx ring lock thread in -net. > > > Actually I'm not so convinced of that. Packet handling is a tradeoff > between > doing process-to-completion on each packet and doing context switches on > batches > of packets. > > Every few years the balance tilts forth and back between > process-to-completion > and batch processing. DragonFly went with a batch-lite token-passing > approach > throughout their kernel. It seems it didn't work out to the extent they > expected. > Now many parts are moving back to the more traditional locking approach.
At least, the per-CPU netisr and other related per-CPU network stuffs (e.g. routing table) work quite well as we have _expected_ (the measured bi-directional IPv4 forwarding performance w/ fastforwarding is 5.6Mpps+, w/o fastforwarding 4.6Mpps+, w/ 4 igb(4) on i7-2600, using 90% cpu time on each HT in Dfly's polling(4) mode); it is _not_ using traditional locking approach on major network paths at all and for IPv4 forwarding Dfly is _not_ doing "process-to-completion". And as a side note: There was a paper compared the message-based parallelism TCP implementation, connection-based thread serialization TCP implementaion (Dfly is using) and connection-based lock serialization TCP implementation. The conclusion was connection-based thread serialization TCP implementation (Dfly is using) had too many scheduling cost. The paper's conclusion _no longer_ holds for Dfly nowadays; we have wiped out major scheduling cost on the hot TCP paths. So as far as I could see, its _not_ the problem of the model itself sometimes, but how the model should be implemented. Best Regards, sephe -- Tomorrow Will Never Die _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
