stop
Jovan Ross
jovanross at msn.com
Tue Apr 2 16:00:28 UTC 2013
please stop emailing me
> From: freebsd-net-request at freebsd.org
> Subject: freebsd-net Digest, Vol 522, Issue 2
> To: freebsd-net at freebsd.org
> Date: Tue, 2 Apr 2013 12:00:02 +0000
>
> Send freebsd-net mailing list submissions to
> freebsd-net at freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> or, via email, send a message with subject or body 'help' to
> freebsd-net-request at freebsd.org
>
> You can reach the person managing the list at
> freebsd-net-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-net digest..."
>
>
> Today's Topics:
>
> 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 at ecanode.com)
> 8. SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier,
> 10G NIC, Server Adapter Intel chipsets (Jean)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 1 Apr 2013 11:22:12 -0400
> From: John Baldwin <jhb at freebsd.org>
> To: freebsd-net at freebsd.org
> Cc: FreeBSD Hackers <freebsd-hackers at freebsd.org>, Andriy Gapon
> <avg at freebsd.org>
> Subject: Re: close(2) while accept(2) is blocked
> Message-ID: <201304011122.13101.jhb at freebsd.org>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Thursday, March 28, 2013 12:54:31 pm Andriy Gapon wrote:
> >
> > So, this started as a simple question, but the answer was quite unexpected to me.
> >
> > 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 close(2).
> > What is going to happen?
> >
> > Turns out that practically nothing. For kernel the close call would be almost a nop.
> > My understanding is this:
> > - when socket is created, its reference count is 1
> > - when accept(2) is called, fget in kernel increments the reference count (kept in
> > an associated struct file)
> > - when close(2) is called, the reference count is decremented
> >
> > The reference count is still greater than zero, so fdrop does not call fo_close.
> > That means that in the case of a socket soclose is not called.
> >
> > I am sure that the reference counting in this case is absolutely correct with
> > respect to managing kernel side structures. But I am not that it is correct with
> > respect to hiding the explicit close(2) call from other threads that may be
> > waiting on the socket.
> > In other words, I am not sure if fo_close is supposed to signify that there are no
> > uses of a file, or that userland close-d the file. Or perhaps these should be two
> > different methods.
> >
> > Additional note is that shutdown(2) doesn't wake up the thread in accept(2)
> > either. At least that's true for unix domain sockets.
> > Not sure if this is a bug.
> >
> > But the summary seems to be is that currently it is not possible to break a thread
> > out of accept(2) (at least without resorting to signals).
>
> I think you need to split the 'struct file' reference count into two different
> 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 equivalent
> to vhold, whereas things like open/dup (and storing an fd in a cmsg) should be
> more like vref. close() should then be a vrele().
>
> --
> John Baldwin
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 01 Apr 2013 11:44:50 -0400
> From: Karim Fodil-Lemelin <fodillemlinkarim at gmail.com>
> To: freebsd-net at freebsd.org
> Subject: Re: igb and ALTQ in 9.1-rc3
> Message-ID: <5159AB72.1050202 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Jack,
>
> I think this would help M. Rogers case as we have done something similar
> here to circumvent the issue and it seems to work well. I would also add
> that when using ALTQ we found it much more stable to set the number of
> queues to 1:
>
> static int igb_num_queues = 1;
>
> Our approach consisted in keeping igb_start() defined and using
> igb_mq_start_locked() inside it instead of igb_start_locked().
>
> Regards,
>
> Karim.
>
>
> On 28/03/2013 7:16 PM, Jack Vogel wrote:
> > Have been kept fairly busy with other matters, 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, but I could change it to be IGB_LEGACY_TX or
> > so,
> > and that could be defined in the Makefile.
> >
> > Would this help?
> >
> > Jack
> >
> >
> > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers <ncrogers at gmail.com> wrote:
> >
> >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel <jfvogel at gmail.com> wrote:
> >>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff <glebius at freebsd.org>
> >> wrote:
> >>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
> >>>> J> UH, maybe asking the owner of the driver would help :)
> >>>> J>
> >>>> J> ... and no, 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, there is some magic implemented in other drivers that makes them
> >>>> modern (that means using if_transmit), but still capable to switch to
> >>>> queueing
> >>>> mode if SIOCADDALTQ was casted upon them.
> >>>>
> >>>>
> >>> Oh, hmmm, 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 at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 1 Apr 2013 13:47:55 -0400
> From: John Baldwin <jhb at freebsd.org>
> To: freebsd-virtualization at freebsd.org
> Cc: freebsd-net at freebsd.org, kindule <kindule at gmail.com>
> Subject: Re: KVM with freeBSD and SR-IOV vlan doesn't working!
> Message-ID: <201304011347.55406.jhb at freebsd.org>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Wednesday, March 27, 2013 5:31:27 am kindule wrote:
> > Recently, we use KVM and SR-IOV in our project. And we choose freeBSD10 as
> > the guest os.As we use the ip address in the igb0 of our freeBSD10 guest, it
> > working no problem.However when i use vlan in our igb0 of the freeBSD10
> > guest,we can see the vlan assigned right and we can ping the vlan address
> > without problem.But we add a gateway of the vlan area.we can't connnected to
> > the gateway.
> > there are some os messages:
> > Host: Debian 7.0 and KVM 1.2
> > Guest: FreeBSD10-current
> >
> > And thanks for your help!
>
> Hmm, does the same vlan setup work on a standalone machine?
>
> --
> John Baldwin
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 1 Apr 2013 13:58:39 -0700
> From: Doug Ambrisko <ambrisko at ambrisko.com>
> To: Richard Tector <richard at tector.org.uk>
> Cc: freebsd-net at freebsd.org
> Subject: Re: Route next-hop interface behaviour
> Message-ID: <20130401205839.GA24595 at ambrisko.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, Mar 31, 2013 at 08:32:19PM +0100, Richard Tector wrote:
> | Hi,
> |
> | I'm not sure if it is expected behaviour but when configuring a static
> | route (default or otherwise) the outbound interface recorded in the
> | table does not update when the system's IP changes interface, even when
> | removing and re-adding it.
> |
> | Fairly simple topology, system running 9.1-STABLE (30th March) with just
> | one of four 'em' interfaces in use - em0 with 10.0.2.199. Default route
> | to 10.0.2.1.
> |
> | Whilst troubleshooting some odd TCP behaviour I thought I'd try a
> | different interface and so downed the active interface and brought up
> | one on a PCI card, and swapped the cable over:
> |
> | # ifconfig em0 down
> | # ifconfig em2 inet 10.0.2.199/24
> | # ifconfig em2 up
> |
> | #####
> | If I then ping an external host it shows as the destination network
> | being inaccessible:
> |
> | root at daffy:~ # ping 212.23.6.76
> | PING 212.23.6.76 (212.23.6.76): 56 data bytes
> | ping: sendto: Network is down
> |
> |
> | #####
> | Can contact the next hop just fine:
> |
> | root at 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=0 ttl=64 time=0.211 ms
> |
> |
> | #####
> | Routing table shows that the default route is still bound to em0 even
> | though the next hop is on em2:
> |
> | root at daffy:~ # netstat -rfinet -n
> | Routing tables
> |
> | Internet:
> | Destination Gateway Flags Refs Use Netif Expire
> | 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
> |
> |
> | #####
> | Removing the default route and re-adding also leaves it on the old
> | interface:
> |
> | root at daffy:~ # route delete default
> | delete net default
> | root at daffy:~ # route add default 10.0.2.1
> | add net default: gateway 10.0.2.1
> | root at daffy:~ # netstat -rfinet -n
> | Routing tables
> |
> | Internet:
> | Destination Gateway Flags Refs Use Netif Expire
> | 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
> |
> | I can understand the initial problem, but surely when I re-add the route
> | it should do a lookup against the table for the next hop, ie.
> | 10.0.2.0/24, and use the associated Netif?
> |
> | What's interesting is that if I remove the IP configuration from em0 it
> | removes the default route above (even though the interface is downed).
> | Re-adding the route works.
>
> You can try this patch:
>
> Index: net/if.c
> ===================================================================
> --- net/if.c (revision 248707)
> +++ net/if.c (working copy)
> @@ -1532,6 +1532,8 @@
>
> IFNET_RLOCK_NOSLEEP();
> TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
> + if ((ifp->if_flags & IFF_UP) == 0)
> + continue;
> IF_ADDR_RLOCK(ifp);
> TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
> if (ifa->ifa_addr->sa_family != addr->sa_family)
> @@ -1620,6 +1622,8 @@
>
> IFNET_RLOCK_NOSLEEP();
> TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
> + if ((ifp->if_flags & IFF_UP) == 0)
> + continue;
> if ((ifp->if_flags & IFF_POINTOPOINT) == 0)
> continue;
> IF_ADDR_RLOCK(ifp);
> @@ -1672,6 +1676,8 @@
> */
> IFNET_RLOCK_NOSLEEP();
> TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
> + if ((ifp->if_flags & IFF_UP) == 0)
> + continue;
> IF_ADDR_RLOCK(ifp);
> TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
> char *cp, *cp2, *cp3;
> Index: net/if_ethersubr.c
> ===================================================================
> --- net/if_ethersubr.c (revision 248707)
> +++ net/if_ethersubr.c (working copy)
> @@ -812,6 +871,11 @@
> #if defined(NETATALK)
> struct llc *l;
> #endif
> + /* Discard packet if interface is not up */
> + if ((ifp->if_flags & IFF_UP) == 0) {
> + m_freem(m);
> + return;
> + }
>
> KASSERT(ifp != NULL, ("%s: NULL interface pointer", __func__));
>
>
> 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.
>
> 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>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 1 Apr 2013 17:22:43 -0700
> From: Nick Rogers <ncrogers at gmail.com>
> To: Karim Fodil-Lemelin <fodillemlinkarim at gmail.com>
> Cc: "freebsd-net at freebsd.org" <freebsd-net at freebsd.org>
> Subject: Re: igb and ALTQ in 9.1-rc3
> Message-ID:
> <CAKOb=YbDW2kMhnAPUetsGeNdtiaOCOmQ2X-9GXW18wwSUZ8j-A at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin
> <fodillemlinkarim at gmail.com> wrote:
> > Hi Jack,
> >
> > I think this would help M. Rogers case as we have done something similar
> > here to circumvent the issue and it seems to work well. I would also add
> > that when using ALTQ we found it much more stable to set the number of
> > queues to 1:
> >
> > static int igb_num_queues = 1;
> >
> > Our approach consisted in keeping igb_start() defined and using
> > igb_mq_start_locked() inside it instead of igb_start_locked().
> >
> > Regards,
> >
> > Karim.
>
> Thanks for the pointer.
>
> 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.
>
> http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=248906&view=markup
> http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.h?revision=248908&view=markup
>
> 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.
>
> 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
>
> Can anyone comment on if the above referenced changes that Jack made
> should be sufficient to get ALTQ working with igb?
>
> 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.
>
> Here is the device check code for reference:
>
> int
> pfctl_add_altq(struct pfctl *pf, struct pf_altq *a)
> {
> if (altqsupport &&
> (loadopt & PFCTL_FLAG_ALTQ) != 0) {
> memcpy(&pf->paltq->altq, a, sizeof(struct pf_altq));
> if ((pf->opts & PF_OPT_NOACTION) == 0) {
> if (ioctl(pf->dev, DIOCADDALTQ, pf->paltq)) {
> if (errno == ENXIO)
> errx(1, "qtype not configured");
> else if (errno == ENODEV)
> errx(1, "%s: driver does not support "
> "altq", a->ifname);
> else
> err(1, "DIOCADDALTQ");
> }
> }
> pfaltq_store(&pf->paltq->altq);
> }
> return (0);
> }
>
>
>
> >
> >
> >
> > On 28/03/2013 7:16 PM, Jack Vogel wrote:
> >>
> >> Have been kept fairly busy with other matters, 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, but I could change it to be IGB_LEGACY_TX
> >> or
> >> so,
> >> and that could be defined in the Makefile.
> >>
> >> Would this help?
> >>
> >> Jack
> >>
> >>
> >> On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers <ncrogers at gmail.com> wrote:
> >>
> >>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel <jfvogel at gmail.com> wrote:
> >>>>
> >>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff <glebius at freebsd.org>
> >>>
> >>> wrote:
> >>>>>
> >>>>> On Mon, Dec 10, 2012 at 03:31:19PM -0800, Jack Vogel wrote:
> >>>>> J> UH, maybe asking the owner of the driver would help :)
> >>>>> J>
> >>>>> J> ... and no, 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, there is some magic implemented in other drivers that makes them
> >>>>> modern (that means using if_transmit), but still capable to switch to
> >>>>> queueing
> >>>>> mode if SIOCADDALTQ was casted upon them.
> >>>>>
> >>>>>
> >>>> Oh, hmmm, 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 at freebsd.org mailing list
> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >>
> >> _______________________________________________
> >> freebsd-net at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >
> >
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 2 Apr 2013 14:16:34 +0800
> From: Sepherosa Ziehau <sepherosa at gmail.com>
> To: Andre Oppermann <andre at freebsd.org>
> Cc: Sami Halabi <sodynet1 at gmail.com>, "Alexander V. Chernikov"
> <melifaro at freebsd.org>, "Alexander V. Chernikov" <melifaro at ipfw.ru>,
> "freebsd-net at freebsd.org" <freebsd-net at freebsd.org>
> Subject: Re: MPLS
> Message-ID:
> <CAMOc5czL9V6LH+xD6OXTA0y6Nc=wMdfiPn_ssANx7yBYHHSDSA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Mar 18, 2013 at 9:41 PM, Andre Oppermann <andre at freebsd.org> wrote:
> > On 18.03.2013 13:20, Alexander V. Chernikov wrote:
> >>
> >> On 17.03.2013, at 23:54, Andre Oppermann <andre at 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
>
>
> ------------------------------
>
> Message: 7
> Date: 2 Apr 2013 00:28:41 -0700
> From: nl at ecanode.com
> To: freebsd-net at freebsd.org
> Subject: Sea Water Electrolyzer for Electro-Chlorination
> Message-ID: <20130402072949.1E486B6 at hub.freebsd.org>
> Content-Type: text/plain; charset="us-ascii"
>
>
> [1]If you can't view this mail click here..
>
> [2]
>
> 2011111721370email.jpg
> __________________________________________________________________
>
>
> [3]Unsubscribeme!
> [4]Update Email Address!
> This email sent to freebsd-net at freebsd.org by [5]nl at ecanode.com Powered
> by
> [6][elogo1.jpg]
>
> References
>
> 1. http://www.ewhizs.com/Preview.aspx?nno=MTAw-T%2f3%2fcheYTl4%3d&mem=14
> 2. http://www.ecanode.com/
> 3. http://www.ewhizs.com/unsubscribeme.aspx?ee=ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc%3d-hJ92ptlVoGg%3d&mem=14
> 4. http://www.ewhizs.com/updat.aspx?ee=ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc%3d-hJ92ptlVoGg%3d&mem=14
> 5. mailto:%20nl at ecanode.com
> 6. http://www.tiaanosoft.com/
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 2 Apr 2013 17:20:26 +0800
> From: Jean <Jean at femrice.com>
> To: freebsd-net <freebsd-net at freebsd.org>
> Subject: SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier,
> 10G NIC, Server Adapter Intel chipsets
> Message-ID: <2013040217202471867312 at femrice.com>
> Content-Type: text/plain; charset="gb2312"
>
> Hello,
>
>
> I am jean and very glad to know you from Google website .Checked your website and maybe your customer need our
>
> products so Write to you and talk about whether we could cooperate with each other in the further .
>
>
> we are the manufacturer of PCI Express 1G &10G Ethernet NIC Card(Server Adapter NIC Cards),Intel chipsets, Our
>
> Femrice brand .CE,FC,ROHS, Stock, lifetime warranty.Very good price in the market.
>
>
> we also supply SFP ,SFP+,XFP and other special modules .
>
>
> The Following one is our mainly NIC Cards:
>
>
> Fiber cards :
>
>
> 1. PCI Express(x4/) Dual Port Gigabit Ethernet NIC Card, Fiber NIC Card , SFP Slot ,LC, Intel82571EB Chipset controller , Type Number : 10002PF
>
>
> 2. PCI Express (x4) Dual Port Gigabit Ethernet NIC Card, Fiber NIC Card ,SFP Slot ,LC, Intel82576EB Chipset controller , Type Number : 10002EF
>
>
> 3.PCI Express(x4) Dual Port Gigabit Ethernet NIC Card, Fiber NIC Card ,SFP Slot ,LC, Intel82580DBChipset controller , Type Number : 1G2DB580-SFP
>
>
> 4. PCI Express (x4) Single Port Gigabit Ethernet NIC Card, Fiber NIC Card ,SFP Slot ,LC, Intel82572EI Chipset controller , Type Number : 10001PF
>
>
> 5. PCI Express (x1) Single Port Gigabit Ethernet NIC Card, Fiber NIC Card ,SFP Slot ,LC, Intel82583 Chipset controller , Type Number : 1GPF583-SFP
>
>
> 6.PCI Express (x8) Dual Port 10G Ethernet NIC Card, Fiber NIC Card ,SFP Slot ,LC, Intel82599ES Chipset controller , Type Number : 10G2BF-SFP+
>
>
> 7. PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card, Fiber , SFP Slot ,LC, Intel82571EB Chipset controller , just Transmissive no
>
> receiver functions Type Number : 1G2BF571-TX (Mainly used in Uni-directional GAP )
>
>
> 8.PCI Express(x4/) Dual Port/Single Port Gigabit Ethernet NIC Card, Fiber , SFP Slot ,LC, Intel82571EB Chipset controller , just Receiver no
>
> transmission functions Type Number : 1G2BF571-RX (Mainly used in Uni-directional GAP )
>
>
>
> Plz reply to me if you are interested in our Products .
>
>
> Hope we have chance to cooperate with each other in the further .
>
>
> If you have Skype or MSN ID is more better ,My skype : Dream-fly99
>
>
> Best Regards
>
>
> Jean heng
>
>
> Femrice (China) Technology Co., Ltd.
>
>
> Tel:0086-10-51266807-813
>
>
> Mobile:0086-13001023615
>
>
> Fax: 0086-10-62979343
>
>
> Email: Jean at femrice.com
>
>
> Websites: http://www.ethernetserveradapter.com/
> www.femrice.com
>
>
> Skype: Dream-fly99
>
>
> MSN: Dream-fly99 at Hotmail.com
>
> ------------------------------
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
> End of freebsd-net Digest, Vol 522, Issue 2
> *******************************************
More information about the freebsd-net
mailing list