Date: Tue, 2 Apr 2013 17:20:26 +0800 From: Jean <Jean@femrice.com> To: freebsd-net <freebsd-net@freebsd.org> Subject: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets Message-ID: <2013040217202471867312@femrice.com>
next in thread | raw e-mail | index | archive | help
SGVsbG8sDQoNCg0KSSBhbSBqZWFuIGFuZCB2ZXJ5IGdsYWQgdG8ga25vdyB5b3UgZnJvbSBHb29n bGUgd2Vic2l0ZSAuQ2hlY2tlZCB5b3VyIHdlYnNpdGUgYW5kIG1heWJlIHlvdXIgY3VzdG9tZXIg bmVlZCBvdXIgDQoNCnByb2R1Y3RzIHNvIFdyaXRlIHRvIHlvdSBhbmQgdGFsayBhYm91dCB3aGV0 aGVyIHdlIGNvdWxkIGNvb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIgaW4gdGhlIGZ1cnRoZXIgLg0K DQoNCndlIGFyZSB0aGUgbWFudWZhY3R1cmVyIG9mIFBDSSBFeHByZXNzIDFHICYxMEcgRXRoZXJu ZXQgTklDIENhcmQoU2VydmVyIEFkYXB0ZXIgTklDIENhcmRzKSxJbnRlbCBjaGlwc2V0cywgT3Vy IA0KDQpGZW1yaWNlIGJyYW5kIC5DRSxGQyxST0hTLCBTdG9jaywgbGlmZXRpbWUgd2FycmFudHku VmVyeSBnb29kIHByaWNlIGluIHRoZSBtYXJrZXQuIA0KDQoNCndlIGFsc28gc3VwcGx5IFNGUCAs U0ZQKyxYRlAgYW5kIG90aGVyIHNwZWNpYWwgbW9kdWxlcyAuDQoNCg0KVGhlIEZvbGxvd2luZyBv bmUgaXMgb3VyIG1haW5seSBOSUMgQ2FyZHM6DQoNCg0KRmliZXIgY2FyZHMgOg0KDQoNCjEuIFBD SSBFeHByZXNzKHg0LykgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVy IE5JQyBDYXJkICwgU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcxRUIgQ2hpcHNldCBjb250cm9sbGVy ICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBGDQoNCg0KMi4gUENJIEV4cHJlc3MgKHg0KSBEdWFsIFBv cnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxM QywgSW50ZWw4MjU3NkVCIENoaXBzZXQgY29udHJvbGxlciAsICBUeXBlIE51bWJlciA6IDEwMDAy RUYNCg0KDQozLlBDSSBFeHByZXNzKHg0KSAgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklD IENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAsTEMsIEludGVsODI1ODBEQkNoaXBzZXQg Y29udHJvbGxlciAsICBUeXBlIE51bWJlciA6IDFHMkRCNTgwLVNGUA0KDQoNCjQuIFBDSSBFeHBy ZXNzICh4NCkgU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklD IENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU3MkVJIENoaXBzZXQgY29udHJvbGxlciAsICBU eXBlIE51bWJlciA6IDEwMDAxUEYNCg0KDQo1LiBQQ0kgRXhwcmVzcyAoeDEpIFNpbmdsZSBQb3J0 IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAsTEMs IEludGVsODI1ODMgQ2hpcHNldCBjb250cm9sbGVyICwgIFR5cGUgTnVtYmVyIDogMUdQRjU4My1T RlANCg0KDQo2LlBDSSBFeHByZXNzICh4OCkgRHVhbCBQb3J0IDEwRyBFdGhlcm5ldCBOSUMgQ2Fy ZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU5OUVTIENoaXBzZXQgY29u dHJvbGxlciAsICBUeXBlIE51bWJlciA6IDEwRzJCRi1TRlArDQoNCg0KNy4gUENJIEV4cHJlc3Mo eDQvKSBEdWFsIFBvcnQvU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmli ZXIgLCBTRlAgU2xvdCAsTEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xsZXIgLCBqdXN0 IFRyYW5zbWlzc2l2ZSBubyANCg0KcmVjZWl2ZXIgZnVuY3Rpb25zIFR5cGUgTnVtYmVyIDogMUcy QkY1NzEtVFggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0KDQoNCjguUENJ IEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQvU2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMg Q2FyZCwgRmliZXIgLCBTRlAgU2xvdCAsTEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xs ZXIgLCBqdXN0IFJlY2VpdmVyIG5vIA0KDQp0cmFuc21pc3Npb24gZnVuY3Rpb25zIFR5cGUgTnVt YmVyIDogMUcyQkY1NzEtUlggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0K DQoNCg0KUGx6IHJlcGx5IHRvIG1lIGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBvdXIgUHJvZHVj dHMgLg0KDQoNCkhvcGUgd2UgaGF2ZSBjaGFuY2UgdG8gY29vcGVyYXRlIHdpdGggZWFjaCBvdGhl ciBpbiB0aGUgZnVydGhlciAuDQoNCg0KSWYgeW91IGhhdmUgU2t5cGUgb3IgTVNOIElEIGlzIG1v cmUgYmV0dGVyICxNeSBza3lwZSA6IERyZWFtLWZseTk5DQoNCg0KQmVzdCBSZWdhcmRzDQoNCg0K SmVhbiBoZW5nDQoNCg0KRmVtcmljZSAoQ2hpbmEpIFRlY2hub2xvZ3kgQ28uLCBMdGQuDQoNCg0K VGVsOjAwODYtMTAtNTEyNjY4MDctODEzIA0KDQoNCk1vYmlsZTowMDg2LTEzMDAxMDIzNjE1DQoN Cg0KRmF4OiAwMDg2LTEwLTYyOTc5MzQzDQoNCg0KRW1haWw6IEplYW5AZmVtcmljZS5jb20gDQoN Cg0KV2Vic2l0ZXM6IGh0dHA6Ly93d3cuZXRoZXJuZXRzZXJ2ZXJhZGFwdGVyLmNvbS8NCiAgICAg ICAgICB3d3cuZmVtcmljZS5jb20gDQoNCg0KU2t5cGU6IERyZWFtLWZseTk5DQoNCg0KTVNOOiBE cmVhbS1mbHk5OUBIb3RtYWlsLmNvbQ== From owner-freebsd-net@FreeBSD.ORG Tue Apr 2 13:01:54 2013 Return-Path: <owner-freebsd-net@FreeBSD.ORG> Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 758405CE; Tue, 2 Apr 2013 13:01:54 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4576613F; Tue, 2 Apr 2013 13:01:54 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id un15so227143pbc.40 for <multiple recipients>; Tue, 02 Apr 2013 06:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zZEydzkkzeTMv1LAKcwI8cxUO69QGnm9d0gcm2iQgvI=; b=GBEEs9p1we6ux8ojpxDb8CL4lMYfEcTE5jnKNJivdynOrfh4wIL5bFWjOYE9Dv/UzX c3MvJEc4kNSkbuiLQHrijVIdapQ7ktUYWhtaKiymw9EkMpTezkqHds1mICBsvHGwoZuN +CHJPoY2CCinUqAvKkh2MbrDfzvLak4N/HTiL9a/5+mK1R9jon7aPcjwi5inUJ8BCFqt S5p8r6fSaDuGW7pnmvsuf5I0Sng6HGZTz/yM8yGxD7gJemJV8uqoN4MCZ1cZdWhVau1+ 8Q69hpoKXXWBvqG4f8aLPfwo9KJUi+yvjmi1C5buGY54kZNHxdsurhjJHvwJnfXwTk3I vJ7w== MIME-Version: 1.0 X-Received: by 10.68.243.98 with SMTP id wx2mr24531069pbc.68.1364907707855; Tue, 02 Apr 2013 06:01:47 -0700 (PDT) Received: by 10.70.34.103 with HTTP; Tue, 2 Apr 2013 06:01:47 -0700 (PDT) In-Reply-To: <CAMOc5czL9V6LH+xD6OXTA0y6Nc=wMdfiPn_ssANx7yBYHHSDSA@mail.gmail.com> References: <CAEW+ogb_b6fYLvcEJdhzRnoyjr0ORto9iNyJ-iiNfniBRnPxmA@mail.gmail.com> <CAEW+ogZTE4Uw-0ROEoSex=VtC+0tChupE2RAW5RFOn=OQEuLLw@mail.gmail.com> <CAEW+ogYbCkCfbFHT0t2v-VmqUkXLGVHgAHPET3X5c2DnsT=Enw@mail.gmail.com> <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> <51471974.3090300@freebsd.org> <CAMOc5czL9V6LH+xD6OXTA0y6Nc=wMdfiPn_ssANx7yBYHHSDSA@mail.gmail.com> Date: Tue, 2 Apr 2013 16:01:47 +0300 Message-ID: <CAEW+ogaUBe_Rhf2WLBELV=FBQC=A6TzWhP3NUqSB+gRLbU5Kdw@mail.gmail.com> Subject: Re: MPLS From: Sami Halabi <sodynet1@gmail.com> To: Sepherosa Ziehau <sepherosa@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" <melifaro@freebsd.org>, Andre Oppermann <andre@freebsd.org>, "Alexander V. Chernikov" <melifaro@ipfw.ru>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>; List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 02 Apr 2013 13:01:54 -0000 >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+ are you talking about the work Luigi did with Netmap? or performance out of the box in GENERIC? Sami On Tue, Apr 2, 2013 at 9:16 AM, Sepherosa Ziehau <sepherosa@gmail.com>wrote: > On Mon, Mar 18, 2013 at 9:41 PM, Andre Oppermann <andre@freebsd.org> > wrote: > > On 18.03.2013 13:20, Alexander V. Chernikov wrote: > >> > >> 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, > >>>>>> 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 > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2013040217202471867312>