SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets
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 ) Copper NIC Cards: 1. PCI Express(x4/) Dual Port Gigabit Ethernet NIC Card, Copper NIC,RJ45 Slot , Intel82571EB Chipset controller , Type Number : 10002PT 2. PCI Express(x4/) Dual Port Gigabit Ethernet NIC Card, Copper NIC,RJ45 Slot , Intel82576EB Chipset controller , Type Number : 10002ET 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 j...@femrice.com.cn 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"
vlan with modified MAC fails to communicate
Hi there! Lately I've been investigating an issue that I would like to share, as I feel I may have to attack it from a different end. I have an ethernet interface from where I create a vlan. Once I set up the ip address in the vlan I can ping correctly on both sides. The issue arrives when I try to change the MAC address of the vlan, as from then on it fails to communicate unless: - I restore vlan's MAC address to its previous value - I enable promisc mode. It's also worth to mention that my current setup is FreeBSD 8.3 and the NIC driver I'm using is not fully mature. I was wondering if this behavior is due to some limitations in the NCI driver I'm using or if in fact it's the correct way to proceed, as it was possible to reproduce this same issue in FreeBSD 8.3 and FreeBSD CURRENT versions, even using more mature NIC drivers as 'em' and 're'. Could somebody please shed some light in this? Thank you. -- Pozdrawiam, Pablo Ribalta Lorenzo ___ 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"
Re: misc/177456: An error of calculating TCP sequence number will resault in the machine to restart
The following reply was made to PR kern/177456; it has been noted by GNATS.
From: Gleb Smirnoff
To: HouYeFei&XiBoLiu
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/177456: An error of calculating TCP sequence number will
resault in the machine to restart
Date: Fri, 29 Mar 2013 16:08:03 +0400
HouYeFei & XiBoLiu,
On Thu, Mar 28, 2013 at 11:55:04PM +, HouYeFei&XiBoLiu wrote:
H> >Number: 177456
H> >Category: misc
H> >Synopsis: An error of calculating TCP sequence number will resault
in the machine to restart
H> >Confidential: no
H> >Severity: non-critical
H> >Priority: low
H> >Responsible:freebsd-bugs
H> >State: open
H> >Quarter:
H> >Keywords:
H> >Date-Required:
H> >Class: sw-bug
H> >Submitter-Id: current-users
H> >Arrival-Date: Fri Mar 29 00:00:00 UTC 2013
H> >Closed-Date:
H> >Last-Modified:
H> >Originator: HouYeFei&XiBoLiu
H> >Release:FreeBSD-9.0
H> >Organization:
H> H3C
H> >Environment:
H> FreeBSD www.unixnotes.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sun May 4
12:36:15 HKT 2012
r...@www.unixnotes.net:/usr/src/sys/i386/compile/unixnotes i386
H> >Description:
H> There is a large number of TCP links between Client and Server, each link
can transmit large amounts of data. When the Client is low on memory, at the
same time it wants to establish a new TCP connection to the server. The
Client sends SYN message and startups retransmission timer, but retransmission
of the first time
H>
H> sends failed because there is not enough mbuf.At this time, a sequence
number is transmitted messages on the tcpcb (tp->snd_nxt) regression. Then
H>
H> a syn+ack message is received and processing the tp->snd_una sequence
number is increased by 1, resault in tp->snd_nxt < th->snd_una. It is likely
that
H>
H> the sending buffer has data to send, but actually is empty, call
H>
H> Tcp_output to send ack to the Server. But Tcp_output enter to the mbuf
replication process, leading to access a null pointer.
I am trying to reproduce the problem, with no success yet.
Can you please clarify the sequence of failures that is required? I understand
your submission in the following way:
Client performs connect(2).
Client TCP stack generates SYN packet, and this packet is lost in network.
Client TCP stack tries to retransmit SYN packet, buf mbuf allocation fails.
Client TCP stack retransmits SYN packet.
Server replies with SYN+ACK.
... and according to you smth should go wrong ...
But in my tests nothing goes wrong. Client successfully retransmits SYN and
connection is established.
This is how I instrument this. I have added special TCP option and set it
before doing connect. The tcp_output() emulates failures that you
described:
Index: tcp_output.c
===
--- tcp_output.c(revision 248873)
+++ tcp_output.c(working copy)
@@ -898,6 +898,13 @@ send:
else
TCPSTAT_INC(tcps_sndwinup);
+ /* Fail allocating second packet. */
+ if (tp->t_flags & TF_ZHOPA && tp->t_zhopa == 1) {
+ tp->t_zhopa = 2;
+ m = NULL;
+ error = ENOBUFS;
+ goto out;
+ } else
m = m_gethdr(M_NOWAIT, MT_DATA);
if (m == NULL) {
error = ENOBUFS;
@@ -1273,6 +1280,13 @@ timer:
if (V_path_mtu_discovery && tp->t_maxopd > V_tcp_minmss)
ip->ip_off |= htons(IP_DF);
+ /* Lose first packet. */
+ if (tp->t_flags & TF_ZHOPA && tp->t_zhopa == 0) {
+ tp->t_zhopa = 1;
+ m_freem(m);
+ error = 0;
+ } else
+
error = ip_output(m, tp->t_inpcb->inp_options, &ro,
((so->so_options & SO_DONTROUTE) ? IP_ROUTETOIF : 0), 0,
tp->t_inpcb);
Am I doing something wrong? Can you provide your way to reproduce this?
Do you have backtrace of the panic?
--
Totus tuus, Glebius.
___
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"
Re: igb and ALTQ in 9.1-rc3
--- On Thu, 3/28/13, Nick Rogers wrote: > From: Nick Rogers > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Jack Vogel" > Cc: "Barney Cordoba" , "Clement Hermann (nodens)" > , "freebsd-net@freebsd.org" > Date: Thursday, March 28, 2013, 9:29 PM > On Thu, Mar 28, 2013 at 4: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? > > I'm currently using ALTQ successfully with the em driver, so > if igb > behaved the same with respect to using if_start instead of > if_transmit > when ALTQ is in play, that would be great. I do not > completely > understand the change you propose as I am not very familiar > with the > driver internals. Any kind of patch or extra > Makefile/make.conf > definition that would allow me to build a 9-STABLE kernel > with an igb > driver that works again with ALTQ, ASAP, would be much > appreciated. > > > > > Jack > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > wrote: > >> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > wrote: > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > Smirnoff > >> > 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. > >> Do yourself a favor and either get a cheap dual port 82571 card or 2 cards and disable the IGB ports. The igb driver is defective, and until they back out the new, untested multi-queue stuff you're just neutering your system trying to use it. Frankly this project made a huge mistake by moving forward with multi queue just for the sake of saying that you support it; without having any credible plan for implementing it. That nonsense that Bill Macy did should have been tarballed up and deposited in the trash folder. The biggest mess in programming history. That being said, the solution is not to hack the igb driver; its to make ALTQ if_transmit compatible, which shouldn't be all that difficult. BC ___ 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"
Re: vlan with modified MAC fails to communicate
--- On Fri, 3/29/13, Pablo Ribalta Lorenzo wrote: > From: Pablo Ribalta Lorenzo > Subject: vlan with modified MAC fails to communicate > To: freebsd-net@freebsd.org > Date: Friday, March 29, 2013, 7:53 AM > Hi there! > > Lately I've been investigating an issue that I would like to > share, as I feel I may have to attack it from a different > end. > > I have an ethernet interface from where I create a vlan. > Once I set up the ip address in the vlan I can ping > correctly on both > sides. The issue arrives when I try to change the MAC > address of the vlan, as from then on it fails to communicate > unless: > > - I restore vlan's MAC address to its previous value > - I enable promisc mode. > > It's also worth to mention that my current setup is FreeBSD > 8.3 and the NIC driver I'm using is not fully mature. > > I was wondering if this behavior is due to some limitations > in the NCI driver I'm using or if in fact it's the correct > way to > proceed, as it was possible to reproduce this same issue in > FreeBSD 8.3 and FreeBSD CURRENT versions, even using more > mature > NIC drivers as 'em' and 're'. > > Could somebody please shed some light in this? Thank you. > Without looking at the code, it's likely that you should be changing the MAC address BEFORE you set up the VLAN. The mac is probably being mapped into some table that being used to track the vlans. BC ___ 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"
Re: vlan with modified MAC fails to communicate
On 03/29/2013 01:57 PM, Barney Cordoba wrote: --- On Fri, 3/29/13, Pablo Ribalta Lorenzo wrote: From: Pablo Ribalta Lorenzo Subject: vlan with modified MAC fails to communicate To: freebsd-net@freebsd.org Date: Friday, March 29, 2013, 7:53 AM Hi there! Lately I've been investigating an issue that I would like to share, as I feel I may have to attack it from a different end. I have an ethernet interface from where I create a vlan. Once I set up the ip address in the vlan I can ping correctly on both sides. The issue arrives when I try to change the MAC address of the vlan, as from then on it fails to communicate unless: - I restore vlan's MAC address to its previous value - I enable promisc mode. It's also worth to mention that my current setup is FreeBSD 8.3 and the NIC driver I'm using is not fully mature. I was wondering if this behavior is due to some limitations in the NCI driver I'm using or if in fact it's the correct way to proceed, as it was possible to reproduce this same issue in FreeBSD 8.3 and FreeBSD CURRENT versions, even using more mature NIC drivers as 'em' and 're'. Could somebody please shed some light in this? Thank you. Without looking at the code, it's likely that you should be changing the MAC address BEFORE you set up the VLAN. The mac is probably being mapped into some table that being used to track the vlans. BC Thanks for your answer Barney, I'm going to extend a little bit the explanation of the issue as it may be too brief. First of all, ifconfig shows me this (mge being the NIC): mge1: flags=8843 metric 0 mtu 1500 options=8000b ether 00:01:01:58:31:30 inet 192.168.126.9 netmask 0xff00 broadcast 192.168.126.255 media: Ethernet autoselect (1000baseT ) status: active vlan1: flags=8843 metric 0 mtu 1500 ether 00:01:01:58:31:30 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge1 Once I set up the ip for vlan1, I'm able to ping outside: #ifconfig vlan1 inet 172.18.0.254 #ping 172.18.0.1 PING 172.18.0.1 (172.18.0.1): 56 data bytes 64 bytes from 172.18.0.1: icmp_seq=0 ttl=64 time=2.511 ms ^C --- 172.18.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss I change MAC address for vlan1 : #ifconfig vlan1 ether 00:0d:01:58:51:30 mge1: flags=8843 metric 0 mtu 1500 options=8000b ether 00:01:01:58:31:30 inet 192.168.126.9 netmask 0xff00 broadcast 192.168.126.255 media: Ethernet autoselect (1000baseT ) status: active vlan1: flags=8843 metric 0 mtu 1500 ether 00:0d:01:58:51:30 inet 172.18.0.254 netmask 0x broadcast 172.18.255.255 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge1 And here is where the problems start, as I'm not able to contact with vlan1 from the outside unless: - Restore the MAC address to be 00:01:01:58:31:30 again - Set up promisc mode As I said, since I was able to see this issue in other platforms and with more mature drivers than my 'mge', I don't know if this is the expected behavior, or my NIC driver is missing something to be able to deal with this situation. However thanks for your hint, I feel I need a little bit of perspective in this issue. -- Pozdrawiam, Pablo Ribalta Lorenzo ___ 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"
Re: vlan with modified MAC fails to communicate
On Fri, Mar 29, 2013 at 10:05 AM, Pablo Ribalta Lorenzo wrote: > Thanks for your answer Barney, > > I'm going to extend a little bit the explanation of the issue as it may be > too brief. > > First of all, ifconfig shows me this (mge being the NIC): > > mge1: flags=8843 metric 0 mtu > 1500 > options=8000b > ether 00:01:01:58:31:30 > inet 192.168.126.9 netmask 0xff00 broadcast 192.168.126.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan1: flags=8843 metric 0 mtu > 1500 > ether 00:01:01:58:31:30 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 100 parent interface: mge1 > > > Once I set up the ip for vlan1, I'm able to ping outside: > > #ifconfig vlan1 inet 172.18.0.254 > > #ping 172.18.0.1 > PING 172.18.0.1 (172.18.0.1): 56 data bytes > 64 bytes from 172.18.0.1: icmp_seq=0 ttl=64 time=2.511 ms > ^C > --- 172.18.0.1 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > > > I change MAC address for vlan1 : > #ifconfig vlan1 ether 00:0d:01:58:51:30 > > mge1: flags=8843 metric 0 mtu > 1500 > options=8000b > ether 00:01:01:58:31:30 > inet 192.168.126.9 netmask 0xff00 broadcast 192.168.126.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan1: flags=8843 metric 0 mtu > 1500 > ether 00:0d:01:58:51:30 > inet 172.18.0.254 netmask 0x broadcast 172.18.255.255 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 100 parent interface: mge1 > > And here is where the problems start, as I'm not able to contact with > vlan1 from the outside unless: > > - Restore the MAC address to be 00:01:01:58:31:30 again > - Set up promisc mode > > As I said, since I was able to see this issue in other platforms and with > more mature drivers than my 'mge', > I don't know if this is the expected behavior, or my NIC driver is missing > something to be able to deal > with this situation. > > However thanks for your hint, I feel I need a little bit of perspective in > this issue. >From a quick glance at if_vlan.c, it doesn't do anything intelligent when you change its MAC address. I also don't know of any ethernet driver in FreeBSD that allows you to use multiple unicast MACs at once (I have some patches for ixgbe, but they aren't ready for prime-time). If you really want to have a different MAC on your vlan interface from its parent you will have to put the parent into promiscuous mode. ___ 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"
Re: vlan with modified MAC fails to communicate
On 29 March 2013 07:37, Ryan Stone wrote: > From a quick glance at if_vlan.c, it doesn't do anything intelligent when > you change its MAC address. I also don't know of any ethernet driver in > FreeBSD that allows you to use multiple unicast MACs at once (I have some > patches for ixgbe, but they aren't ready for prime-time). If you really > want to have a different MAC on your vlan interface from its parent you > will have to put the parent into promiscuous mode. > > The ath(4) NICs do - for multi-VAP hostap (and soon, multi-STA) support. But the NICs have a BSS Mask register which lets the NIC pass through packets that match a filter, rather than having to put it into promiscuous mode. Adrian ___ 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"
RE: igb and ALTQ in 9.1-rc3
-Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Barney Cordoba Sent: Friday, March 29, 2013 5:51 AM To: Jack Vogel; Nick Rogers Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) Subject: Re: igb and ALTQ in 9.1-rc3 --- On Thu, 3/28/13, Nick Rogers wrote: > From: Nick Rogers > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Jack Vogel" > Cc: "Barney Cordoba" , "Clement Hermann (nodens)" > , "freebsd-net@freebsd.org" > Date: Thursday, March 28, 2013, 9:29 PM > On Thu, Mar 28, 2013 at 4: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? > > I'm currently using ALTQ successfully with the em driver, so > if igb > behaved the same with respect to using if_start instead of > if_transmit > when ALTQ is in play, that would be great. I do not > completely > understand the change you propose as I am not very familiar > with the > driver internals. Any kind of patch or extra > Makefile/make.conf > definition that would allow me to build a 9-STABLE kernel > with an igb > driver that works again with ALTQ, ASAP, would be much > appreciated. > > > > > Jack > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > wrote: > >> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > wrote: > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > Smirnoff > >> > 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. > >> > >Do yourself a favor and either get a cheap dual port 82571 card or >2 cards and disable the IGB ports. The igb driver is defective, and until >they back out the new, untested multi-queue stuff you're just neutering >your system trying to use it. > >Frankly this project made a huge mistake by moving forward with multi >queue just for the sake of saying that you support it; without having >any credible plan for implementing it. That nonsense that Bill Macy did >should have been tarballed up and deposited in the trash folder. The >biggest mess in programming history. > >That being said, the solution is not to hack the igb driver; its to make >ALTQ if_transmit compatible, which shouldn't be all that difficult. > >BC I may be misunderstanding what you are saying, but if the solution is, as you say "not to hack the igb driver", then how is it defective in this case? Or are you just directing vitriol toward Intel? Multi-queue is working fine in igb. Jeff ___ 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"
RE: igb and ALTQ in 9.1-rc3
--- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > From: Pieper, Jeffrey E > Subject: RE: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" , "Jack Vogel" > , "Nick Rogers" > Cc: "freebsd-net@freebsd.org" , "Clement Hermann > (nodens)" > Date: Friday, March 29, 2013, 11:45 AM > > > -Original Message- > From: owner-freebsd-...@freebsd.org > [mailto:owner-freebsd-...@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4: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? > > > > I'm currently using ALTQ successfully with the em > driver, so > > if igb > > behaved the same with respect to using if_start instead > of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very > familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE > kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > 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. > > >> > > > >Do yourself a favor and either get a cheap dual port > 82571 card or > >2 cards and disable the IGB ports. The igb driver is > defective, and until > >they back out the new, untested multi-queue stuff you're > just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving > forward with multi > >queue just for the sake of saying that you support it; > without having > >any credible plan for implementing it. That nonsense > that Bill Macy did > >should have been tarballed up and deposited in the trash > folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb > driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that > difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the > solution is, as you say "not to hack the igb driver", then > how is it defective in this case? Or are you just directing > vitriol toward Intel? Multi-queue is working fine in igb. > > Jeff It's defective because it's been poorly implemented and has more bugs than a Manhattan hotel bed. Adding queues without a proper plan just add more lock contention. It's not a production-ready driver. As Jack once said, Intel doesn't care about performance, they're just example drivers. igb is an example of how not to do things. BC ___ freebsd-net
Re: igb and ALTQ in 9.1-rc3
Barney, Patches gratefully accepted. Adrian On 29 March 2013 08:54, Barney Cordoba wrote: > > > --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > > > From: Pieper, Jeffrey E > > Subject: RE: igb and ALTQ in 9.1-rc3 > > To: "Barney Cordoba" , "Jack Vogel" < > jfvo...@gmail.com>, "Nick Rogers" > > Cc: "freebsd-net@freebsd.org" , "Clement > Hermann (nodens)" > > Date: Friday, March 29, 2013, 11:45 AM > > > > > > -Original Message- > > From: owner-freebsd-...@freebsd.org > > [mailto:owner-freebsd-...@freebsd.org] > > On Behalf Of Barney Cordoba > > Sent: Friday, March 29, 2013 5:51 AM > > To: Jack Vogel; Nick Rogers > > Cc: freebsd-net@freebsd.org; > > Clement Hermann (nodens) > > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > > > > > --- On Thu, 3/28/13, Nick Rogers > > wrote: > > > > > From: Nick Rogers > > > Subject: Re: igb and ALTQ in 9.1-rc3 > > > To: "Jack Vogel" > > > Cc: "Barney Cordoba" , > > "Clement Hermann (nodens)" , > > "freebsd-net@freebsd.org" > > > > > Date: Thursday, March 28, 2013, 9:29 PM > > > On Thu, Mar 28, 2013 at 4: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? > > > > > > I'm currently using ALTQ successfully with the em > > driver, so > > > if igb > > > behaved the same with respect to using if_start instead > > of > > > if_transmit > > > when ALTQ is in play, that would be great. I do not > > > completely > > > understand the change you propose as I am not very > > familiar > > > with the > > > driver internals. Any kind of patch or extra > > > Makefile/make.conf > > > definition that would allow me to build a 9-STABLE > > kernel > > > with an igb > > > driver that works again with ALTQ, ASAP, would be much > > > appreciated. > > > > > > > > > > > Jack > > > > > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > > > wrote: > > > >> > > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > > > wrote: > > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > > Smirnoff > > > >> > 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. > > > >> > > > > > >Do yourself a favor and either get a cheap dual port > > 82571 card or > > >2 cards and disable the IGB ports. The igb driver is > > defective, and until > > >they back out the new, untested multi-queue stuff you're > > just neutering > > >your system trying to use it. > > > > > >Frankly this project made a huge mistake by moving > > forward with multi > > >queue just for the sake of saying that you support it; > > without having > > >any credible plan for implementing it. That nonsense > > that Bill Macy did > > >should have been tarballed up and deposited in the trash > > folder. The > > >biggest mess in programming history. > > > > > >That being said, the solution is not to hack the igb > > driver; its to make > > >ALTQ if_transmit compatible, which shouldn't be all that > > difficult. > > > > > >BC > > > > I may be misunderstanding what you are saying, but if the > > solution is, as you say "not to hack the igb driver", then > > how is it defective in this case? Or are you just directing > > vitr
RE: igb and ALTQ in 9.1-rc3
--- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > From: Pieper, Jeffrey E > Subject: RE: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" , "Jack Vogel" > , "Nick Rogers" > Cc: "freebsd-net@freebsd.org" , "Clement Hermann > (nodens)" > Date: Friday, March 29, 2013, 11:45 AM > > > -Original Message- > From: owner-freebsd-...@freebsd.org > [mailto:owner-freebsd-...@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4: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? > > > > I'm currently using ALTQ successfully with the em > driver, so > > if igb > > behaved the same with respect to using if_start instead > of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very > familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE > kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > 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. > > >> > > > >Do yourself a favor and either get a cheap dual port > 82571 card or > >2 cards and disable the IGB ports. The igb driver is > defective, and until > >they back out the new, untested multi-queue stuff you're > just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving > forward with multi > >queue just for the sake of saying that you support it; > without having > >any credible plan for implementing it. That nonsense > that Bill Macy did > >should have been tarballed up and deposited in the trash > folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb > driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that > difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the > solution is, as you say "not to hack the igb driver", then > how is it defective in this case? Or are you just directing > vitriol toward Intel? Multi-queue is working fine in igb. > > Jeff It works like crap. Your definition of "works" is that it doesnt crash. Mine is that it works better with multiple queues than with 1, which it doesn't. And if you load a system up, it will blow up with multiqueue before it will with 1 queue. The point of using Multiqueue isn't to exhaust all of the cpus instead of just 2. It's to get past the wall of using only 2 cpus when they're exhausted
Re: igb and ALTQ in 9.1-rc3
Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago realized its pointless to attempt anything like a fair conversation with him. The only thing he's ever contributed is slander and pseudo-critique... another poison thread I'm done with. Jack On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E < jeffrey.e.pie...@intel.com> wrote: > > > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , "Clement Hermann > (nodens)" , "freebsd-net@freebsd.org" < > freebsd-net@freebsd.org> > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4: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? > > > > I'm currently using ALTQ successfully with the em driver, so > > if igb > > behaved the same with respect to using if_start instead of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > 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. > > >> > > > >Do yourself a favor and either get a cheap dual port 82571 card or > >2 cards and disable the IGB ports. The igb driver is defective, and until > >they back out the new, untested multi-queue stuff you're just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving forward with multi > >queue just for the sake of saying that you support it; without having > >any credible plan for implementing it. That nonsense that Bill Macy did > >should have been tarballed up and deposited in the trash folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that difficult. > > > >BC > > I may be misunderstanding what you are saying, but if the solution is, as > you say "not to hack the igb driver", then how is it defective in this > case? Or are you just directing vitriol toward Intel? Multi-queue is > working fine in igb. > > Jeff > > ___ > 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 unsubs
Re: igb and ALTQ in 9.1-rc3
it needs a lot more than a patch. It needs to be completely re-thunk --- On Fri, 3/29/13, Adrian Chadd wrote: From: Adrian Chadd Subject: Re: igb and ALTQ in 9.1-rc3 To: "Barney Cordoba" Cc: "Jack Vogel" , "Nick Rogers" , "Jeffrey EPieper" , "freebsd-net@freebsd.org" , "Clement Hermann (nodens)" Date: Friday, March 29, 2013, 12:07 PM Barney, Patches gratefully accepted. Adrian On 29 March 2013 08:54, Barney Cordoba wrote: --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > From: Pieper, Jeffrey E > Subject: RE: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" , "Jack Vogel" > , "Nick Rogers" > Cc: "freebsd-net@freebsd.org" , "Clement Hermann > (nodens)" > Date: Friday, March 29, 2013, 11:45 AM > > > -Original Message- > From: owner-freebsd-...@freebsd.org > [mailto:owner-freebsd-...@freebsd.org] > On Behalf Of Barney Cordoba > Sent: Friday, March 29, 2013 5:51 AM > To: Jack Vogel; Nick Rogers > Cc: freebsd-net@freebsd.org; > Clement Hermann (nodens) > Subject: Re: igb and ALTQ in 9.1-rc3 > > > > --- On Thu, 3/28/13, Nick Rogers > wrote: > > > From: Nick Rogers > > Subject: Re: igb and ALTQ in 9.1-rc3 > > To: "Jack Vogel" > > Cc: "Barney Cordoba" , > "Clement Hermann (nodens)" , > "freebsd-net@freebsd.org" > > > Date: Thursday, March 28, 2013, 9:29 PM > > On Thu, Mar 28, 2013 at 4: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? > > > > I'm currently using ALTQ successfully with the em > driver, so > > if igb > > behaved the same with respect to using if_start instead > of > > if_transmit > > when ALTQ is in play, that would be great. I do not > > completely > > understand the change you propose as I am not very > familiar > > with the > > driver internals. Any kind of patch or extra > > Makefile/make.conf > > definition that would allow me to build a 9-STABLE > kernel > > with an igb > > driver that works again with ALTQ, ASAP, would be much > > appreciated. > > > > > > > > Jack > > > > > > > > > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > > > wrote: > > >> > > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > > > wrote: > > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb > > Smirnoff > > >> > 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. > > >> > > > >Do yourself a favor and either get a cheap dual port > 82571 card or > >2 cards and disable the IGB ports. The igb driver is > defective, and until > >they back out the new, untested multi-queue stuff you're > just neutering > >your system trying to use it. > > > >Frankly this project made a huge mistake by moving > forward with multi > >queue just for the sake of saying that you support it; > without having > >any credible plan for implementing it. That nonsense > that Bill Macy did > >should have been tarballed up and deposited in the trash > folder. The > >biggest mess in programming history. > > > >That being said, the solution is not to hack the igb > driver; its to make > >ALTQ if_transmit compatible, which shouldn't be all that > difficult. > > > >BC > > I may be misunderstanding what you are s
Re: igb and ALTQ in 9.1-rc3
Comedy gold. It's been a while since I've seen this much idiocy from you, Barney. Hopefully the rest of the mailing list will blackhole you, as I'm about to, and we can all get back to real work. Scott On Mar 29, 2013, at 10:38 AM, Barney Cordoba wrote: > it needs a lot more than a patch. It needs to be completely re-thunk > > --- On Fri, 3/29/13, Adrian Chadd wrote: > > From: Adrian Chadd > Subject: Re: igb and ALTQ in 9.1-rc3 > To: "Barney Cordoba" > Cc: "Jack Vogel" , "Nick Rogers" , > "Jeffrey EPieper" , "freebsd-net@freebsd.org" > , "Clement Hermann (nodens)" > Date: Friday, March 29, 2013, 12:07 PM > > Barney, > Patches gratefully accepted. > > > > Adrian > > > > On 29 March 2013 08:54, Barney Cordoba wrote: > > > > > > --- On Fri, 3/29/13, Pieper, Jeffrey E wrote: > > > >> From: Pieper, Jeffrey E > >> Subject: RE: igb and ALTQ in 9.1-rc3 > >> To: "Barney Cordoba" , "Jack Vogel" >> , "Nick Rogers" > > >> Cc: "freebsd-net@freebsd.org" , "Clement Hermann >> (nodens)" > > >> Date: Friday, March 29, 2013, 11:45 AM > >> > >> > >> -Original Message- > >> From: owner-freebsd-...@freebsd.org > >> [mailto:owner-freebsd-...@freebsd.org] > >> On Behalf Of Barney Cordoba > >> Sent: Friday, March 29, 2013 5:51 AM > >> To: Jack Vogel; Nick Rogers > >> Cc: freebsd-net@freebsd.org; > >> Clement Hermann (nodens) > >> Subject: Re: igb and ALTQ in 9.1-rc3 > >> > >> > >> > >> --- On Thu, 3/28/13, Nick Rogers > >> wrote: > >> > >>> From: Nick Rogers > >>> Subject: Re: igb and ALTQ in 9.1-rc3 > >>> To: "Jack Vogel" > >>> Cc: "Barney Cordoba" , > >> "Clement Hermann (nodens)" , > >> "freebsd-net@freebsd.org" > >> > >>> Date: Thursday, March 28, 2013, 9:29 PM > >>> On Thu, Mar 28, 2013 at 4: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? > >>> > >>> I'm currently using ALTQ successfully with the em > >> driver, so > >>> if igb > >>> behaved the same with respect to using if_start instead > >> of > >>> if_transmit > >>> when ALTQ is in play, that would be great. I do not > >>> completely > >>> understand the change you propose as I am not very > >> familiar > >>> with the > >>> driver internals. Any kind of patch or extra > >>> Makefile/make.conf > >>> definition that would allow me to build a 9-STABLE > >> kernel > >>> with an igb > >>> driver that works again with ALTQ, ASAP, would be much > >>> appreciated. > >>> > > Jack > > > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers > >> > >>> wrote: > > > > On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel > >> > >>> wrote: > >> On Mon, Dec 10, 2012 at 11:58 PM, Gleb > >>> Smirnoff > >> 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. > > > >>> > >>> Do yourself a favor and either get a cheap dual port > >> 82571 card or > >>> 2 cards and disable the IGB ports. The igb driver is > >> defective, and until > >>> they back out the new, untested multi-queue stuff you're
Re: igb and ALTQ in 9.1-rc3
On Fri, Mar 29, 2013 at 9:36 AM, Jack Vogel wrote: > Fortunately, Barney doesn't speak for me, or for Intel, and I've long ago > realized its pointless to > attempt anything like a fair conversation with him. The only thing he's ever > contributed is slander > and pseudo-critique... another poison thread I'm done with. > > Jack Multiqueue or not, I would appreciate any help with this thread's original issue. Whether or not its the ideal thing to do, I cannot simply just replace the NICs with an em(4) variant, as I have hundreds of customers/systems already in production running 8.3 and relying on the igb driver + ALTQ. I need to be able to upgrade these systems to 9.1 without making hardware changes. > > > > On Fri, Mar 29, 2013 at 8:45 AM, Pieper, Jeffrey E > wrote: >> >> >> >> -Original Message- >> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] >> On Behalf Of Barney Cordoba >> Sent: Friday, March 29, 2013 5:51 AM >> To: Jack Vogel; Nick Rogers >> Cc: freebsd-net@freebsd.org; Clement Hermann (nodens) >> Subject: Re: igb and ALTQ in 9.1-rc3 >> >> >> >> --- On Thu, 3/28/13, Nick Rogers wrote: >> >> > From: Nick Rogers >> > Subject: Re: igb and ALTQ in 9.1-rc3 >> > To: "Jack Vogel" >> > Cc: "Barney Cordoba" , "Clement Hermann >> > (nodens)" , "freebsd-net@freebsd.org" >> > >> > Date: Thursday, March 28, 2013, 9:29 PM >> > On Thu, Mar 28, 2013 at 4: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? >> > >> > I'm currently using ALTQ successfully with the em driver, so >> > if igb >> > behaved the same with respect to using if_start instead of >> > if_transmit >> > when ALTQ is in play, that would be great. I do not >> > completely >> > understand the change you propose as I am not very familiar >> > with the >> > driver internals. Any kind of patch or extra >> > Makefile/make.conf >> > definition that would allow me to build a 9-STABLE kernel >> > with an igb >> > driver that works again with ALTQ, ASAP, would be much >> > appreciated. >> > >> > > >> > > Jack >> > > >> > > >> > > >> > > On Thu, Mar 28, 2013 at 2:31 PM, Nick Rogers >> > wrote: >> > >> >> > >> On Tue, Dec 11, 2012 at 1:09 AM, Jack Vogel >> > wrote: >> > >> > On Mon, Dec 10, 2012 at 11:58 PM, Gleb >> > Smirnoff >> > >> > 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. >> > >> >> > >> >Do yourself a favor and either get a cheap dual port 82571 card or >> >2 cards and disable the IGB ports. The igb driver is defective, and until >> >they back out the new, untested multi-queue stuff you're just neutering >> >your system trying to use it. >> > >> >Frankly this project made a huge mistake by moving forward with multi >> >queue just for the sake of saying that you support it; without having >> >any credible plan for implementing it. That nonsense that Bill Macy did >> >should have been tarballed up and deposited in the trash folder. The >> >biggest mess in programming history. >> > >> >That being said, the solution is not to hack the igb driver; its to make >> >ALTQ if_transmit compatible, which shouldn't be all that difficult. >> > >> >BC >> >> I may be misunderstanding what you are saying, but if the solution is, as >> you say "not
Re: igb and ALTQ in 9.1-rc3
On 29 March 2013 10:04, Nick Rogers wrote: > Multiqueue or not, I would appreciate any help with this thread's > original issue. Whether or not its the ideal thing to do, I cannot > simply just replace the NICs with an em(4) variant, as I have hundreds > of customers/systems already in production running 8.3 and relying on > the igb driver + ALTQ. I need to be able to upgrade these systems to > 9.1 without making hardware changes. > > If it's that critical, have you thought about contracting out that task to a developer? adrian ___ 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"
Re: close(2) while accept(2) is blocked
On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon wrote: > 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). > This is a known problem for Java. Closing a socket that another thread is block on is supposed to unblock a thread and throw a SocketException. http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#close() In other operating systems, such as Solaris and MacOS X, closing the descriptor causes blocked system calls to return with an error. FreeBSD (and Linux) do not behave this way. There, a JVM must do extra bookkeeping to associate file descriptors with threads blocked on the descriptor. This allows the close method to identify blocked threads and send them a signal. On those threads the caller of the blocking method must further distinguish an error return as being caused by a signal sent on behalf of close. It is not obvious whether there is any benefit to having the current blocking behaviour. Threads are an afterthought in UNIX so this could just be an oversight. It would make a high-level language runtimes simpler if FreeBSD behaved more like Solaris and MacOS X. ___ 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"
Re: close(2) while accept(2) is blocked
On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro wrote: > > In other operating systems, such as Solaris and MacOS X, closing the > descriptor causes blocked system calls to return with an error. What happens if you select() on a socket and another thread closes this socket? Ideally select() should return (with EINTR?) so that the blocking thread can some cleanup action. And if you do that, the blocking accept() case is not really different. There is no point in *not* telling blocking threads that the descriptor they're waiting on is one EBADF and nothing is going to happen. > It is not obvious whether there is any benefit to having the current > blocking behaviour. This may need some new kernel code but IMHO this is worth fixing. ___ 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"
IPsec crash in TCP, also NFS DRC patches (was: Re: Limits on jumbo mbuf cluster allocation)
< said: > The patch includes a lot of drc2.patch and drc3.patch, so don't try > and apply it to a patched kernel. Hopefully it will apply cleanly to > vanilla sources. > Tha patch has been minimally tested. Well, it's taken a long time, but I was finally able to get some testing. The user whose OpenStack cluster jobs had eaten previous file servers killed this one, too, but not in a way that's attributable to the NFS code. He was able to put on a fairly heavy load from about 630 virtual machines in our cluster without the server even getting particularly busy. Another cluster job, however, repeatedly panicked the server. Thankfully, there's a backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8074ee11 stack pointer = 0x28:0xff9a469ee6d0 frame pointer = 0x28:0xff9a469ee710 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq260: ix0:que 3) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1ce trap_fatal() at trap_fatal+0x290 trap_pfault() at trap_pfault+0x21c trap() at trap+0x365 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8074ee11, rsp = 0xff9a469ee6d0, rbp = 0xff9a469ee710 --- ipsec_getpolicybysock() at ipsec_getpolicybysock+0x31 ipsec46_in_reject() at ipsec46_in_reject+0x24 ipsec4_in_reject() at ipsec4_in_reject+0x9 tcp_input() at tcp_input+0x498 ip_input() at ip_input+0x1de netisr_dispatch_src() at netisr_dispatch_src+0x20b ether_demux() at ether_demux+0x14d ether_nh_input() at ether_nh_input+0x1f4 netisr_dispatch_src() at netisr_dispatch_src+0x20b ixgbe_rxeof() at ixgbe_rxeof+0x1cb ixgbe_msix_que() at ixgbe_msix_que+0xa8 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa6 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff9a469eecf0, rbp = 0 --- ipsec_setspidx_inpcb() is inlined here; the fault is on the line: error = ipsec_setspidx(m, &inp->inp_sp->sp_in->spidx, 1); where inp->inp_sp is being dereferenced: 0x8074ee02 : mov0xf0(%rdx),%rax 0x8074ee09 : mov$0x1,%edx 0x8074ee0e : mov%rcx,%r15 0x8074ee11 : mov(%rax),%rsi <-- FAULT! 0x8074ee14 : add$0x34,%rsi 0x8074ee18 : callq 0x8074e6f0 (inp is in %rdx here). The crash occurs when the clients are making about 200 connections per second. (We're not sure if this is by design or if it's a broken NAT implementation on the OpenStack nodes. My money is on a broken NAT, because we were also seeing lots of data being sent on apparently-closed connections. The kernel was also logging many [ECONNABORTED] errors when nfsd tried to accept() new client connections. A capture is available if anyone wants to look at this in more detail, although obviously not from the traffic that actually caused the crash.) inp_sp is declared thus: struct inpcbpolicy *inp_sp;/* (s) for IPSEC */ The locking code "(s)" is supposed to indicate "protected by another subsystem's locks", but there is no locking at all in ipsec_getpolicybysock(), so that seems to be a misstatement at best. I quickly installed a new kernel with IPSEC disabled (we have no need for it), and it seems to have survived further abuse, although it seems that the user's test jobs were winding down at that time as well so I can't say for certain that it wouldn't have crashed somewhere else. -GAWollman ___ 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"
