please stop emailing me
> From: freebsd-net-requ...@freebsd.org > Subject: freebsd-net Digest, Vol 522, Issue 2 > To: freebsd-net@freebsd.org > Date: Tue, 2 Apr 2013 12:00:02 +0000 > > Send freebsd-net mailing list submissions to > freebsd-net@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-requ...@freebsd.org > > You can reach the person managing the list at > freebsd-net-ow...@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 (n...@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 <j...@freebsd.org> > To: freebsd-net@freebsd.org > Cc: FreeBSD Hackers <freebsd-hack...@freebsd.org>, Andriy Gapon > <a...@freebsd.org> > Subject: Re: close(2) while accept(2) is blocked > Message-ID: <201304011122.13101....@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 <fodillemlinka...@gmail.com> > To: freebsd-net@freebsd.org > Subject: Re: igb and ALTQ in 9.1-rc3 > Message-ID: <5159ab72.1050...@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 <ncrog...@gmail.com> wrote: > > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel <jfvo...@gmail.com> wrote: > >>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff <gleb...@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@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > _______________________________________________ > > 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" > > > > ------------------------------ > > Message: 3 > Date: Mon, 1 Apr 2013 13:47:55 -0400 > From: John Baldwin <j...@freebsd.org> > To: freebsd-virtualizat...@freebsd.org > Cc: freebsd-net@freebsd.org, kindule <kind...@gmail.com> > Subject: Re: KVM with freeBSD and SR-IOV vlan doesn't working! > Message-ID: <201304011347.55406....@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 <ambri...@ambrisko.com> > To: Richard Tector <rich...@tector.org.uk> > Cc: freebsd-net@freebsd.org > Subject: Re: Route next-hop interface behaviour > Message-ID: <20130401205839.ga24...@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@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@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@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@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 > | > | 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 <ncrog...@gmail.com> > To: Karim Fodil-Lemelin <fodillemlinka...@gmail.com> > Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> > Subject: Re: igb and ALTQ in 9.1-rc3 > Message-ID: > <CAKOb=ybdw2kmhnapuetsgendtiaocomq2x-9gxw18wwsuz8...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Apr 1, 2013 at 8:44 AM, Karim Fodil-Lemelin > <fodillemlinka...@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 <ncrog...@gmail.com> wrote: > >> > >>> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel <jfvo...@gmail.com> wrote: > >>>> > >>>> On Mon, Dec 10, 2012 at 11:58 PM, Gleb Smirnoff <gleb...@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@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > >> > >> _______________________________________________ > >> 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" > > > > > > _______________________________________________ > > 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" > > > ------------------------------ > > Message: 6 > Date: Tue, 2 Apr 2013 14:16:34 +0800 > From: Sepherosa Ziehau <sepher...@gmail.com> > To: Andre Oppermann <an...@freebsd.org> > Cc: Sami Halabi <sodyn...@gmail.com>, "Alexander V. Chernikov" > <melif...@freebsd.org>, "Alexander V. Chernikov" <melif...@ipfw.ru>, > "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> > Subject: Re: MPLS > Message-ID: > <CAMOc5czL9V6LH+xD6OXTA0y6Nc=wmdfipn_ssanx7ybyhhs...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 18, 2013 at 9:41 PM, Andre Oppermann <an...@freebsd.org> wrote: > > On 18.03.2013 13:20, Alexander V. Chernikov wrote: > >> > >> 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. > > > > > > 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: n...@ecanode.com > To: freebsd-net@freebsd.org > Subject: Sea Water Electrolyzer for Electro-Chlorination > Message-ID: <20130402072949.1e48...@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@freebsd.org by [5]n...@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:%2...@ecanode.com > 6. http://www.tiaanosoft.com/ > > > ------------------------------ > > Message: 8 > Date: Tue, 2 Apr 2013 17:20:26 +0800 > From: Jean <j...@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: <2013040217202471867...@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: j...@femrice.com > > > Websites: http://www.ethernetserveradapter.com/ > www.femrice.com > > > Skype: Dream-fly99 > > > MSN: dream-fl...@hotmail.com > > ------------------------------ > > _______________________________________________ > 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" > > End of freebsd-net Digest, Vol 522, Issue 2 > ******************************************* _______________________________________________ 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"
