Date: Mon, 18 Mar 2013 13:20:30 +0100 From: "Alexander V. Chernikov" <melifaro@ipfw.ru> To: Andre Oppermann <andre@freebsd.org> Cc: Sami Halabi <sodynet1@gmail.com>, "Alexander V. Chernikov" <melifaro@FreeBSD.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: MPLS Message-ID: <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> In-Reply-To: <514649A5.4090200@freebsd.org> References: <CAEW%2Bogb_b6fYLvcEJdhzRnoyjr0ORto9iNyJ-iiNfniBRnPxmA@mail.gmail.com> <CAEW%2BogZTE4Uw-0ROEoSex=VtC%2B0tChupE2RAW5RFOn=OQEuLLw@mail.gmail.com> <CAEW%2BogYbCkCfbFHT0t2v-VmqUkXLGVHgAHPET3X5c2DnsT=Enw@mail.gmail.com> <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17.03.2013, at 23:54, Andre Oppermann <andre@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, mayb= e >> Their control plane code is mostly useless due to design approach (routin= g daemons talk via kernel). >=20 > What's your approach? It is actually not mine. We have discussed this a bit in radix-related threa= d. Generally quagga/bird (and other hiperf hardware-accelerated and software= routers) have feature-rich RIb from which best routes (possibly multipath) a= re installed to kernel/fib. Kernel main task should be to do efficient looku= ps while every other advanced feature should be implemented in userland. >=20 >> Their data plane code, well.. Yes, we can use some defines from their hea= ders, but that's all :) >>>> porting it would be short and more straight forward than porting linux L= DP >>>> implementation of BIRD. >>=20 >> 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 ch= ages in our netisr/ethernet >> handling code. >=20 > Can you explain what changes you think are necessary and why? We definitely need ability to dispatch chain of mbufs - this was already dis= cussed in intel rx ring lock thread in -net. Currently significant number of drivers support interrupt moderation permitt= ing several/tens/hundreds of packets to be received on interrupt. For each packet we have to run some basic checks, PFIL hooks, netisr code, l= 3 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 wo= rks bad for non-hashable types of traffic like gre, PPPoE, MPLS. Additionall= y, hashing function is either standard (from M$ NDIS) or documented permitti= ng someone malicious to generate 'special' traffic matching single queue. Currently even if we can add m2flowid/m2cpu function able to hash, say, gre o= r MPLS, it is unefficient since we have to lock/unlock netisr queues for eve= ry packet.=20 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. A= fter 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 >=20 > --=20 > Andre >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3659B942-7C37-431F-8945-C8A5BCD8DC67>