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. > >> 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. Currently significant number of drivers support interrupt moderation permitting several/tens/hundreds of packets to be received on interrupt. For each packet we have to run some basic checks, PFIL hooks, netisr code, l3 code resulting in many locks being acquired/released per each packet. Typically we rely on NIC to put packet in given queue (direct isr), which works bad for non-hashable types of traffic like gre, PPPoE, MPLS. Additionally, hashing function is either standard (from M$ NDIS) or documented permitting someone malicious to generate 'special' traffic matching single queue.
Currently even if we can add m2flowid/m2cpu function able to hash, say, gre or MPLS, it is unefficient since we have to lock/unlock netisr queues for every packet. I'm thinking of * utilizing m_nextpkt field in mbuf header * adding some nh_chain flag to netisr If given netisr does not support flag and nextpkt is not null we simply call such netisr in cycle. * netisr hash function accepts mbuf 'chain' and pointer to array (Sizeof N * ptr), sorts mbuf to N netisr queues saving list heads to supplied array. After that we put given lists to appropriate queues. * teach ethersubr RX code to deal with mbuf chains (not easy one) * add some partial support of handling chains to fastfwd code > > -- > Andre > > _______________________________________________ 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"
