Date: Tue, 2 Apr 2013 12:00:20 -0400 From: Jovan Ross <jovanross@msn.com> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: stop Message-ID: <BLU151-W36ADF88C6EC054CF5E2E90A4DF0@phx.gbl> In-Reply-To: <mailman.81.1364904002.54369.freebsd-net@freebsd.org> References: <mailman.81.1364904002.54369.freebsd-net@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
please stop emailing me > From: freebsd-net-request@freebsd.org > Subject: freebsd-net Digest=2C Vol 522=2C Issue 2 > To: freebsd-net@freebsd.org > Date: Tue=2C 2 Apr 2013 12:00:02 +0000 >=20 > Send freebsd-net mailing list submissions to > freebsd-net@freebsd.org >=20 > To subscribe or unsubscribe via the World Wide Web=2C visit > http://lists.freebsd.org/mailman/listinfo/freebsd-net > or=2C via email=2C send a message with subject or body 'help' to > freebsd-net-request@freebsd.org >=20 > You can reach the person managing the list at > freebsd-net-owner@freebsd.org >=20 > When replying=2C please edit your Subject line so it is more specific > than "Re: Contents of freebsd-net digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: close(2) while accept(2) is blocked (John Baldwin) > 2. Re: igb and ALTQ in 9.1-rc3 (Karim Fodil-Lemelin) > 3. Re: KVM with freeBSD and SR-IOV vlan doesn't working! > (John Baldwin) > 4. Re: Route next-hop interface behaviour (Doug Ambrisko) > 5. Re: igb and ALTQ in 9.1-rc3 (Nick Rogers) > 6. Re: MPLS (Sepherosa Ziehau) > 7. Sea Water Electrolyzer for Electro-Chlorination (nl@ecanode.com) > 8. SFP/SFP+ =2C PCI Express Gigabit Ethernet NIC Card supplier=2C > 10G NIC=2C Server Adapter Intel chipsets (Jean) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon=2C 1 Apr 2013 11:22:12 -0400 > From: John Baldwin <jhb@freebsd.org> > To: freebsd-net@freebsd.org > Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>=2C Andriy Gapon > <avg@freebsd.org> > Subject: Re: close(2) while accept(2) is blocked > Message-ID: <201304011122.13101.jhb@freebsd.org> > Content-Type: Text/Plain=3B charset=3D"iso-8859-1" >=20 > On Thursday=2C March 28=2C 2013 12:54:31 pm Andriy Gapon wrote: > >=20 > > So=2C this started as a simple question=2C but the answer was quite une= xpected to me. > >=20 > > Let's say we have an opened and listen-ed socket and let's assume that = we know > > that one thread is blocked in accept(2) and another thread is calling c= lose(2). > > What is going to happen? > >=20 > > Turns out that practically nothing. For kernel the close call would be= almost a nop. > > My understanding is this: > > - when socket is created=2C its reference count is 1 > > - when accept(2) is called=2C fget in kernel increments the reference c= ount (kept in > > an associated struct file) > > - when close(2) is called=2C the reference count is decremented > >=20 > > The reference count is still greater than zero=2C so fdrop does not cal= l fo_close. > > That means that in the case of a socket soclose is not called. > >=20 > > I am sure that the reference counting in this case is absolutely correc= t with > > respect to managing kernel side structures. But I am not that it is co= rrect with > > respect to hiding the explicit close(2) call from other threads that ma= y be > > waiting on the socket. > > In other words=2C I am not sure if fo_close is supposed to signify that= there are no > > uses of a file=2C or that userland close-d the file. Or perhaps these = should be two > > different methods. > >=20 > > Additional note is that shutdown(2) doesn't wake up the thread in accep= t(2) > > either. At least that's true for unix domain sockets. > > Not sure if this is a bug. > >=20 > > But the summary seems to be is that currently it is not possible to bre= ak a thread > > out of accept(2) (at least without resorting to signals). >=20 > I think you need to split the 'struct file' reference count into two diff= erent > counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. = The > fget for accept and probably most other system calls should probably be e= quivalent > to vhold=2C whereas things like open/dup (and storing an fd in a cmsg) sh= ould be > more like vref. close() should then be a vrele(). >=20 > --=20 > John Baldwin >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Mon=2C 01 Apr 2013 11:44:50 -0400 > From: Karim Fodil-Lemelin <fodillemlinkarim@gmail.com> > To: freebsd-net@freebsd.org > Subject: Re: igb and ALTQ in 9.1-rc3 > Message-ID: <5159AB72.1050202@gmail.com> > Content-Type: text/plain=3B charset=3DISO-8859-1=3B format=3Dflowed >=20 > Hi Jack=2C >=20 > I think this would help M. Rogers case as we have done something similar= =20 > here to circumvent the issue and it seems to work well. I would also add= =20 > that when using ALTQ we found it much more stable to set the number of=20 > queues to 1: >=20 > static int igb_num_queues =3D 1=3B >=20 > Our approach consisted in keeping igb_start() defined and using=20 > igb_mq_start_locked() inside it instead of igb_start_locked(). >=20 > Regards=2C >=20 > Karim. >=20 >=20 > On 28/03/2013 7:16 PM=2C Jack Vogel wrote: > > Have been kept fairly busy with other matters=2C one thing I could do s= hort > > term is > > change the defines in igb the way I did in the em driver so you could s= till > > define > > the older if_start entry. Right now those are based on OS version and s= o > > you will > > automatically get if_transmit=2C but I could change it to be IGB_LEGACY= _TX or > > so=2C > > and that could be defined in the Makefile. > > > > Would this help? > > > > Jack > > > > > > On Thu=2C Mar 28=2C 2013 at 2:31 PM=2C Nick Rogers <ncrogers@gmail.com>= wrote: > > > >> On Tue=2C Dec 11=2C 2012 at 1:09 AM=2C Jack Vogel <jfvogel@gmail.com> = wrote: > >>> On Mon=2C Dec 10=2C 2012 at 11:58 PM=2C Gleb Smirnoff <glebius@freebs= d.org> > >> wrote: > >>>> On Mon=2C Dec 10=2C 2012 at 03:31:19PM -0800=2C Jack Vogel wrote: > >>>> J> UH=2C maybe asking the owner of the driver would help :) > >>>> J> > >>>> J> ... and no=2C I've never been aware of doing anything to stop > >> supporting > >>>> altq > >>>> J> so you wouldn't see any commits. If there's something in the altq > >> code > >>>> or > >>>> J> support (which I have nothing to do with) that caused this no-one > >>>> informed > >>>> J> me. > >>>> > >>>> Switching from if_start to if_transmit effectively disables ALTQ > >> support. > >>>> AFAIR=2C there is some magic implemented in other drivers that makes= them > >>>> modern (that means using if_transmit)=2C but still capable to switch= to > >>>> queueing > >>>> mode if SIOCADDALTQ was casted upon them. > >>>> > >>>> > >>> Oh=2C hmmm=2C I'll look into the matter after my vacation. > >>> > >>> Jack > >> Has there been any progress on resolving this issue? I recently ran > >> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am > >> wondering what the latest recommendation is. I've used ALTQ and igb > >> successfully for years and it is unfortunate it no longer works. > >> Appreciate any advice. > >> > >>> _______________________________________________ > >>> freebsd-net@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>> To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.o= rg" > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org= " >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Mon=2C 1 Apr 2013 13:47:55 -0400 > From: John Baldwin <jhb@freebsd.org> > To: freebsd-virtualization@freebsd.org > Cc: freebsd-net@freebsd.org=2C kindule <kindule@gmail.com> > Subject: Re: KVM with freeBSD and SR-IOV vlan doesn't working! > Message-ID: <201304011347.55406.jhb@freebsd.org> > Content-Type: Text/Plain=3B charset=3D"iso-8859-1" >=20 > On Wednesday=2C March 27=2C 2013 5:31:27 am kindule wrote: > > Recently=2C we use KVM and SR-IOV in our project. And we choose freeBSD= 10 as > > the guest os.As we use the ip address in the igb0 of our freeBSD10 gues= t=2C it > > working no problem.However when i use vlan in our igb0 of the freeBSD10 > > guest=2Cwe can see the vlan assigned right and we can ping the vlan add= ress > > without problem.But we add a gateway of the vlan area.we can't connnect= ed to > > the gateway. > > there are some os messages: > > Host: Debian 7.0 and KVM 1.2 > > Guest: FreeBSD10-current > >=20 > > And thanks for your help! >=20 > Hmm=2C does the same vlan setup work on a standalone machine? >=20 > --=20 > John Baldwin >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Mon=2C 1 Apr 2013 13:58:39 -0700 > From: Doug Ambrisko <ambrisko@ambrisko.com> > To: Richard Tector <richard@tector.org.uk> > Cc: freebsd-net@freebsd.org > Subject: Re: Route next-hop interface behaviour > Message-ID: <20130401205839.GA24595@ambrisko.com> > Content-Type: text/plain=3B charset=3D"us-ascii" >=20 > On Sun=2C Mar 31=2C 2013 at 08:32:19PM +0100=2C Richard Tector wrote: > | Hi=2C > |=20 > | I'm not sure if it is expected behaviour but when configuring a static= =20 > | route (default or otherwise) the outbound interface recorded in the=20 > | table does not update when the system's IP changes interface=2C even wh= en=20 > | removing and re-adding it. > |=20 > | Fairly simple topology=2C system running 9.1-STABLE (30th March) with j= ust=20 > | one of four 'em' interfaces in use - em0 with 10.0.2.199. Default route= =20 > | to 10.0.2.1. > |=20 > | Whilst troubleshooting some odd TCP behaviour I thought I'd try a=20 > | different interface and so downed the active interface and brought up=20 > | one on a PCI card=2C and swapped the cable over: > |=20 > | # ifconfig em0 down > | # ifconfig em2 inet 10.0.2.199/24 > | # ifconfig em2 up > |=20 > | ##### > | If I then ping an external host it shows as the destination network=20 > | being inaccessible: > |=20 > | root@daffy:~ # ping 212.23.6.76 > | PING 212.23.6.76 (212.23.6.76): 56 data bytes > | ping: sendto: Network is down > |=20 > |=20 > | ##### > | Can contact the next hop just fine: > |=20 > | root@daffy:~ # ping 10.0.2.1 > | PING 10.0.2.1 (10.0.2.1): 56 data bytes > | 64 bytes from 10.0.2.1: icmp_seq=3D0 ttl=3D64 time=3D0.211 ms > |=20 > |=20 > | ##### > | Routing table shows that the default route is still bound to em0 even=20 > | though the next hop is on em2: > |=20 > | root@daffy:~ # netstat -rfinet -n > | Routing tables > |=20 > | Internet: > | Destination Gateway Flags Refs Use Netif Exp= ire > | default 10.0.2.1 UGS 0 3141 em0 > | ^^^ > | 10.0.2.0/24 link#4 U 1 255 em2 > | 10.0.2.199 link#1 UHS 1 0 lo0 > | 127.0.0.1 link#9 UH 0 0 lo0 > |=20 > |=20 > | ##### > | Removing the default route and re-adding also leaves it on the old=20 > | interface: > |=20 > | root@daffy:~ # route delete default > | delete net default > | root@daffy:~ # route add default 10.0.2.1 > | add net default: gateway 10.0.2.1 > | root@daffy:~ # netstat -rfinet -n > | Routing tables > |=20 > | Internet: > | Destination Gateway Flags Refs Use Netif Exp= ire > | default 10.0.2.1 UGS 0 0 em0 > | 10.0.2.0/24 link#4 U 0 688 em2 > | 10.0.2.199 link#1 UHS 1 0 lo0 > | 127.0.0.1 link#9 UH 0 0 lo0 > |=20 > | I can understand the initial problem=2C but surely when I re-add the ro= ute=20 > | it should do a lookup against the table for the next hop=2C ie.=20 > | 10.0.2.0/24=2C and use the associated Netif? > |=20 > | What's interesting is that if I remove the IP configuration from em0 it= =20 > | removes the default route above (even though the interface is downed).= =20 > | Re-adding the route works. >=20 > You can try this patch: >=20 > Index: net/if.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/if.c (revision 248707) > +++ net/if.c (working copy) > @@ -1532=2C6 +1532=2C8 @@ > =20 > IFNET_RLOCK_NOSLEEP()=3B > TAILQ_FOREACH(ifp=2C &V_ifnet=2C if_link) { > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) > + continue=3B > IF_ADDR_RLOCK(ifp)=3B > TAILQ_FOREACH(ifa=2C &ifp->if_addrhead=2C ifa_link) { > if (ifa->ifa_addr->sa_family !=3D addr->sa_family) > @@ -1620=2C6 +1622=2C8 @@ > =20 > IFNET_RLOCK_NOSLEEP()=3B > TAILQ_FOREACH(ifp=2C &V_ifnet=2C if_link) { > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) > + continue=3B > if ((ifp->if_flags & IFF_POINTOPOINT) =3D=3D 0) > continue=3B > IF_ADDR_RLOCK(ifp)=3B > @@ -1672=2C6 +1676=2C8 @@ > */ > IFNET_RLOCK_NOSLEEP()=3B > TAILQ_FOREACH(ifp=2C &V_ifnet=2C if_link) { > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) > + continue=3B > IF_ADDR_RLOCK(ifp)=3B > TAILQ_FOREACH(ifa=2C &ifp->if_addrhead=2C ifa_link) { > char *cp=2C *cp2=2C *cp3=3B > Index: net/if_ethersubr.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/if_ethersubr.c (revision 248707) > +++ net/if_ethersubr.c (working copy) > @@ -812=2C6 +871=2C11 @@ > #if defined(NETATALK) > struct llc *l=3B > #endif > + /* Discard packet if interface is not up */ > + if ((ifp->if_flags & IFF_UP) =3D=3D 0) { > + m_freem(m)=3B > + return=3B > + } > =20 > KASSERT(ifp !=3D NULL=2C ("%s: NULL interface pointer"=2C __func__))=3B > =20 >=20 > The issue is that the routing doesn't look to see if the NIC is > up or not. It just looks at the IP address. So it tries to send > it out the first matching NIC that could be down. >=20 > Doug A. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: up.patch > Type: text/x-diff > Size: 1318 bytes > Desc: not available > URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20130401= /22156a69/attachment-0001.patch> >=20 > ------------------------------ >=20 > Message: 5 > Date: Mon=2C 1 Apr 2013 17:22:43 -0700 > From: Nick Rogers <ncrogers@gmail.com> > To: Karim Fodil-Lemelin <fodillemlinkarim@gmail.com> > Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> > Subject: Re: igb and ALTQ in 9.1-rc3 > Message-ID: > <CAKOb=3DYbDW2kMhnAPUetsGeNdtiaOCOmQ2X-9GXW18wwSUZ8j-A@mail.gmail.com> > Content-Type: text/plain=3B charset=3DISO-8859-1 >=20 > On Mon=2C Apr 1=2C 2013 at 8:44 AM=2C Karim Fodil-Lemelin > <fodillemlinkarim@gmail.com> wrote: > > Hi Jack=2C > > > > I think this would help M. Rogers case as we have done something simila= r > > here to circumvent the issue and it seems to work well. I would also ad= d > > that when using ALTQ we found it much more stable to set the number of > > queues to 1: > > > > static int igb_num_queues =3D 1=3B > > > > Our approach consisted in keeping igb_start() defined and using > > igb_mq_start_locked() inside it instead of igb_start_locked(). > > > > Regards=2C > > > > Karim. >=20 > Thanks for the pointer. >=20 > I've been working with Jack to get a fix for this in that downgrades > the stack to the older if_start/non-multiqueue interface. See the > following two commits he made to HEAD. >=20 > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=3D248= 906&view=3Dmarkup > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=3D248= 908&view=3Dmarkup >=20 > I've applied these changes to latest 9.1-STABLE src and included the > IGB_LEGACY_TX in the e1000 Makefile. So far I am not having any luck > getting pfctl to think igb is supported. >=20 > i.e. I am still getting the following when loading my PF config: > pfctl -f /etc/pf.conf > pfctl: igb0: driver does not support altq >=20 > Can anyone comment on if the above referenced changes that Jack made > should be sufficient to get ALTQ working with igb? >=20 > The error is coming from src/contrib/pf/pfctl/pfctl.c. There seems to > be a function that checks if the driver is supported or not but I > cannot figure out why the ioctl is not returning a device. >=20 > Here is the device check code for reference: >=20 > int > pfctl_add_altq(struct pfctl *pf=2C struct pf_altq *a) > { > if (altqsupport && > (loadopt & PFCTL_FLAG_ALTQ) !=3D 0) { > memcpy(&pf->paltq->altq=2C a=2C sizeof(struct pf_altq))= =3B > if ((pf->opts & PF_OPT_NOACTION) =3D=3D 0) { > if (ioctl(pf->dev=2C DIOCADDALTQ=2C pf->paltq)) { > if (errno =3D=3D ENXIO) > errx(1=2C "qtype not configured")= =3B > else if (errno =3D=3D ENODEV) > errx(1=2C "%s: driver does not su= pport " > "altq"=2C a->ifname)=3B > else > err(1=2C "DIOCADDALTQ")=3B > } > } > pfaltq_store(&pf->paltq->altq)=3B > } > return (0)=3B > } >=20 >=20 >=20 > > > > > > > > On 28/03/2013 7:16 PM=2C Jack Vogel wrote: > >> > >> Have been kept fairly busy with other matters=2C one thing I could do = short > >> term is > >> change the defines in igb the way I did in the em driver so you could > >> still > >> define > >> the older if_start entry. Right now those are based on OS version and = so > >> you will > >> automatically get if_transmit=2C but I could change it to be IGB_LEGAC= Y_TX > >> or > >> so=2C > >> and that could be defined in the Makefile. > >> > >> Would this help? > >> > >> Jack > >> > >> > >> On Thu=2C Mar 28=2C 2013 at 2:31 PM=2C Nick Rogers <ncrogers@gmail.com= > wrote: > >> > >>> On Tue=2C Dec 11=2C 2012 at 1:09 AM=2C Jack Vogel <jfvogel@gmail.com>= wrote: > >>>> > >>>> On Mon=2C Dec 10=2C 2012 at 11:58 PM=2C Gleb Smirnoff <glebius@freeb= sd.org> > >>> > >>> wrote: > >>>>> > >>>>> On Mon=2C Dec 10=2C 2012 at 03:31:19PM -0800=2C Jack Vogel wrote: > >>>>> J> UH=2C maybe asking the owner of the driver would help :) > >>>>> J> > >>>>> J> ... and no=2C I've never been aware of doing anything to stop > >>> > >>> supporting > >>>>> > >>>>> altq > >>>>> J> so you wouldn't see any commits. If there's something in the alt= q > >>> > >>> code > >>>>> > >>>>> or > >>>>> J> support (which I have nothing to do with) that caused this no-on= e > >>>>> informed > >>>>> J> me. > >>>>> > >>>>> Switching from if_start to if_transmit effectively disables ALTQ > >>> > >>> support. > >>>>> > >>>>> AFAIR=2C there is some magic implemented in other drivers that make= s them > >>>>> modern (that means using if_transmit)=2C but still capable to switc= h to > >>>>> queueing > >>>>> mode if SIOCADDALTQ was casted upon them. > >>>>> > >>>>> > >>>> Oh=2C hmmm=2C I'll look into the matter after my vacation. > >>>> > >>>> Jack > >>> > >>> Has there been any progress on resolving this issue? I recently ran > >>> into this problem upgrading my servers from 8.3 to 9.1-RELEASE and am > >>> wondering what the latest recommendation is. I've used ALTQ and igb > >>> successfully for years and it is unfortunate it no longer works. > >>> Appreciate any advice. > >>> > >>>> _______________________________________________ > >>>> freebsd-net@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>>> To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.= org" > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.or= g" > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org= " >=20 >=20 > ------------------------------ >=20 > Message: 6 > Date: Tue=2C 2 Apr 2013 14:16:34 +0800 > From: Sepherosa Ziehau <sepherosa@gmail.com> > To: Andre Oppermann <andre@freebsd.org> > Cc: Sami Halabi <sodynet1@gmail.com>=2C "Alexander V. Chernikov" > <melifaro@freebsd.org>=2C "Alexander V. Chernikov" <melifaro@ipfw.ru>=2C > "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> > Subject: Re: MPLS > Message-ID: > <CAMOc5czL9V6LH+xD6OXTA0y6Nc=3DwMdfiPn_ssANx7yBYHHSDSA@mail.gmail.com> > Content-Type: text/plain=3B charset=3DISO-8859-1 >=20 > On Mon=2C Mar 18=2C 2013 at 9:41 PM=2C Andre Oppermann <andre@freebsd.org= > wrote: > > On 18.03.2013 13:20=2C Alexander V. Chernikov wrote: > >> > >> On 17.03.2013=2C at 23:54=2C Andre Oppermann <andre@freebsd.org> wrote= : > >> > >>> On 17.03.2013 19:57=2C Alexander V. Chernikov wrote: > >>>> > >>>> On 17.03.2013 13:20=2C Sami Halabi wrote: > >>>>>> > >>>>>> ITOH OpenBSD has a complete implementation of MPLS out of the box= =2C > >>>>>> 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 a= nd > >> software routers) have feature-rich RIb from which best routes (possib= ly > >> multipath) are installed to kernel/fib. Kernel main task should be to = do > >> efficient lookups while every other advanced feature should be impleme= nted > >> in userland. > > > > > > Yes=2C we have started discussing it but haven't reached a conclusion a= mong > > 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=2C well.. Yes=2C we can use some defines from = their > >>>> headers=2C but that's all :) > >>>>>> > >>>>>> porting it would be short and more straight forward than porting l= inux > >>>>>> LDP > >>>>>> implementation of BIRD. > >>>> > >>>> > >>>> It is not 'linux' implementation. LDP itself is cross-platform. > >>>> The most tricky place here is control plane. > >>>> However=2C making _fast_ MPLS switching is tricky too=2C since it re= quires > >>>> 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 alrea= dy > >> 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 o= n > > 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 the= y > > expected. > > Now many parts are moving back to the more traditional locking approach= . >=20 > At least=2C 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+=2C w/o fastforwarding 4.6Mpps+=2C w/ 4 igb(4) on i7-2600=2C > using 90% cpu time on each HT in Dfly's polling(4) mode)=3B it is _not_ > using traditional locking approach on major network paths at all and > for IPv4 forwarding Dfly is _not_ doing "process-to-completion". >=20 > And as a side note: There was a paper compared the message-based > parallelism TCP implementation=2C 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=3B we have wiped out major scheduling cost on the hot TCP > paths. So as far as I could see=2C its _not_ the problem of the model > itself sometimes=2C but how the model should be implemented. >=20 > Best Regards=2C > sephe >=20 > -- > Tomorrow Will Never Die >=20 >=20 > ------------------------------ >=20 > Message: 7 > Date: 2 Apr 2013 00:28:41 -0700 > From: nl@ecanode.com > To: freebsd-net@freebsd.org > Subject: Sea Water Electrolyzer for Electro-Chlorination > Message-ID: <20130402072949.1E486B6@hub.freebsd.org> > Content-Type: text/plain=3B charset=3D"us-ascii" >=20 >=20 > [1]If you can't view this mail click here.. >=20 > [2] >=20 > 2011111721370email.jpg > __________________________________________________________________ >=20 >=20 > [3]Unsubscribeme! > [4]Update Email Address! > This email sent to freebsd-net@freebsd.org by [5]nl@ecanode.com Powered > = by > [6][elogo= 1.jpg] >=20 > References >=20 > 1. http://www.ewhizs.com/Preview.aspx?nno=3DMTAw-T%2f3%2fcheYTl4%3d&me= m=3D14 > 2. http://www.ecanode.com/ > 3. http://www.ewhizs.com/unsubscribeme.aspx?ee=3DZnJlZWJzZC1uZXRAZnJlZ= WJzZC5vcmc%3d-hJ92ptlVoGg%3d&mem=3D14 > 4. http://www.ewhizs.com/updat.aspx?ee=3DZnJlZWJzZC1uZXRAZnJlZWJzZC5vc= mc%3d-hJ92ptlVoGg%3d&mem=3D14 > 5. mailto:%20nl@ecanode.com > 6. http://www.tiaanosoft.com/ >=20 >=20 > ------------------------------ >=20 > Message: 8 > Date: Tue=2C 2 Apr 2013 17:20:26 +0800 > From: Jean <Jean@femrice.com> > To: freebsd-net <freebsd-net@freebsd.org> > Subject: SFP/SFP+ =2C PCI Express Gigabit Ethernet NIC Card supplier=2C > 10G NIC=2C Server Adapter Intel chipsets > Message-ID: <2013040217202471867312@femrice.com> > Content-Type: text/plain=3B charset=3D"gb2312" >=20 > Hello=2C >=20 >=20 > I am jean and very glad to know you from Google website .Checked your web= site and maybe your customer need our=20 >=20 > products so Write to you and talk about whether we could cooperate with e= ach other in the further . >=20 >=20 > we are the manufacturer of PCI Express 1G &10G Ethernet NIC Card(Server A= dapter NIC Cards)=2CIntel chipsets=2C Our=20 >=20 > Femrice brand .CE=2CFC=2CROHS=2C Stock=2C lifetime warranty.Very good pri= ce in the market.=20 >=20 >=20 > we also supply SFP =2CSFP+=2CXFP and other special modules . >=20 >=20 > The Following one is our mainly NIC Cards: >=20 >=20 > Fiber cards : >=20 >=20 > 1. PCI Express(x4/) Dual Port Gigabit Ethernet NIC Card=2C Fiber NIC Card= =2C SFP Slot =2CLC=2C Intel82571EB Chipset controller =2C Type Number : 10= 002PF >=20 >=20 > 2. PCI Express (x4) Dual Port Gigabit Ethernet NIC Card=2C Fiber NIC Card= =2CSFP Slot =2CLC=2C Intel82576EB Chipset controller =2C Type Number : 10= 002EF >=20 >=20 > 3.PCI Express(x4) Dual Port Gigabit Ethernet NIC Card=2C Fiber NIC Card = =2CSFP Slot =2CLC=2C Intel82580DBChipset controller =2C Type Number : 1G2D= B580-SFP >=20 >=20 > 4. PCI Express (x4) Single Port Gigabit Ethernet NIC Card=2C Fiber NIC Ca= rd =2CSFP Slot =2CLC=2C Intel82572EI Chipset controller =2C Type Number : = 10001PF >=20 >=20 > 5. PCI Express (x1) Single Port Gigabit Ethernet NIC Card=2C Fiber NIC Ca= rd =2CSFP Slot =2CLC=2C Intel82583 Chipset controller =2C Type Number : 1G= PF583-SFP >=20 >=20 > 6.PCI Express (x8) Dual Port 10G Ethernet NIC Card=2C Fiber NIC Card =2CS= FP Slot =2CLC=2C Intel82599ES Chipset controller =2C Type Number : 10G2BF-= SFP+ >=20 >=20 > 7. PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card=2C Fi= ber =2C SFP Slot =2CLC=2C Intel82571EB Chipset controller =2C just Transmis= sive no=20 >=20 > receiver functions Type Number : 1G2BF571-TX (Mainly used in Uni-directio= nal GAP ) >=20 >=20 > 8.PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card=2C Fib= er =2C SFP Slot =2CLC=2C Intel82571EB Chipset controller =2C just Receiver = no=20 >=20 > transmission functions Type Number : 1G2BF571-RX (Mainly used in Uni-dire= ctional GAP ) >=20 >=20 >=20 > Plz reply to me if you are interested in our Products . >=20 >=20 > Hope we have chance to cooperate with each other in the further . >=20 >=20 > If you have Skype or MSN ID is more better =2CMy skype : Dream-fly99 >=20 >=20 > Best Regards >=20 >=20 > Jean heng >=20 >=20 > Femrice (China) Technology Co.=2C Ltd. >=20 >=20 > Tel:0086-10-51266807-813=20 >=20 >=20 > Mobile:0086-13001023615 >=20 >=20 > Fax: 0086-10-62979343 >=20 >=20 > Email: Jean@femrice.com=20 >=20 >=20 > Websites: http://www.ethernetserveradapter.com/ > www.femrice.com=20 >=20 >=20 > Skype: Dream-fly99 >=20 >=20 > MSN: Dream-fly99@Hotmail.com >=20 > ------------------------------ >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 > End of freebsd-net Digest=2C Vol 522=2C Issue 2 > ******************************************* =
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BLU151-W36ADF88C6EC054CF5E2E90A4DF0>