Re: ix(intel) vs mlxen(mellanox) 10Gb performance
Yonghyeon PYUN wrote: > On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: > > Hans Petter Selasky wrote: > > > On 08/19/15 09:42, Yonghyeon PYUN wrote: > > > > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: > > > >> On 08/18/15 23:54, Rick Macklem wrote: > > > >>> Ouch! Yes, I now see that the code that counts the # of mbufs is > > > >>> before > > > >>> the > > > >>> code that adds the tcp/ip header mbuf. > > > >>> > > > >>> In my opinion, this should be fixed by setting if_hw_tsomaxsegcount > > > >>> to > > > >>> whatever > > > >>> the driver provides - 1. It is not the driver's responsibility to > > > >>> know if > > > >>> a tcp/ip > > > >>> header mbuf will be added and is a lot less confusing that expecting > > > >>> the > > > >>> driver > > > >>> author to know to subtract one. (I had mistakenly thought that > > > >>> tcp_output() had > > > >>> added the tc/ip header mbuf before the loop that counts mbufs in the > > > >>> list. > > > >>> Btw, > > > >>> this tcp/ip header mbuf also has leading space for the MAC layer > > > >>> header.) > > > >>> > > > >> > > > >> Hi Rick, > > > >> > > > >> Your question is good. With the Mellanox hardware we have separate > > > >> so-called inline data space for the TCP/IP headers, so if the TCP > > > >> stack > > > >> subtracts something, then we would need to add something to the limit, > > > >> because then the scatter gather list is only used for the data part. > > > >> > > > > > > > > I think all drivers in tree don't subtract 1 for > > > > if_hw_tsomaxsegcount. Probably touching Mellanox driver would be > > > > simpler than fixing all other drivers in tree. > > > > > > > >> Maybe it can be controlled by some kind of flag, if all the three TSO > > > >> limits should include the TCP/IP/ethernet headers too. I'm pretty sure > > > >> we want both versions. > > > >> > > > > > > > > Hmm, I'm afraid it's already complex. Drivers have to tell almost > > > > the same information to both bus_dma(9) and network stack. > > > > > > Don't forget that not all drivers in the tree set the TSO limits before > > > if_attach(), so possibly the subtraction of one TSO fragment needs to go > > > into ip_output() > > > > > Ok, I realized that some drivers may not know the answers before > > ether_ifattach(), > > due to the way they are configured/written (I saw the use of > > if_hw_tsomax_update() > > in the patch). > > I was not able to find an interface that configures TSO parameters > after if_t conversion. I'm under the impression > if_hw_tsomax_update() is not designed to use this way. Probably we > need a better one?(CCed to Gleb). > > > > > If it is subtracted as a part of the assignment to if_hw_tsomaxsegcount in > > tcp_output() > > at line#791 in tcp_output() like the following, I don't think it should > > matter if the > > values are set before ether_ifattach()? > > /* > > * Subtract 1 for the tcp/ip header mbuf that > > * will be prepended to the mbuf chain in this > > * function in the code below this block. > > */ > > if_hw_tsomaxsegcount = tp->t_tsomaxsegcount - 1; > > > > I don't have a good solution for the case where a driver doesn't plan on > > using the > > tcp/ip header provided by tcp_output() except to say the driver can add one > > to the > > setting to compensate for that (and if they fail to do so, it still works, > > although > > somewhat suboptimally). When I now read the comment in sys/net/if_var.h it > > is clear > > what it means, but for some reason I didn't read it that way before? (I > > think it was > > the part that said the driver didn't have to subtract for the headers that > > confused me?) > > In any case, we need to try and come up with a clear definition of what > > they need to > > be set to. > > > > I can now think of two ways to deal with this: > > 1 - Leave tcp_output() as is, but provide a macro for the device driver > > authors to use > > that sets if_hw_tsomaxsegcount with a flag for "driver uses tcp/ip > > header mbuf", > > documenting that this flag should normally be true. > > OR > > 2 - Change tcp_output() as above, noting that this is a workaround for > > confusion w.r.t. > > whether or not if_hw_tsomaxsegcount should include the tcp/ip header > > mbuf and > > update the comment in if_var.h to reflect this. Then drivers that don't > > use the > > tcp/ip header mbuf can increase their value for if_hw_tsomaxsegcount by > > 1. > > (The comment should also mention that a value of 35 or greater is much > > preferred to > > 32 if the hardware will support that.) > > > > Both works for me. My preference is 2 just because it's very > common for most drivers that use tcp/ip header mbuf. Thanks for this comment. I tend to agree, both for the reason you state and also because the patch is simple enough that it might quali
Re: Will 10.2 also ship with a very stale NTP?
On Fri, 2015-08-21 at 08:51 +0200, Harald Schmalzbauer wrote: > Bezüglich Ian Lepore's Nachricht vom 21.08.2015 00:34 (localtime): > > On Fri, 2015-07-24 at 15:19 +0200, Harald Schmalzbauer wrote: > >> Bezglich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime): > >>> And let's all just hope that a week or two of testing is enough when > >>> jumping a major piece of software forward several years in its > >>> independent evolution. > >> … > >>> I wonder how many other such things could be lurking in 4.2.8, waiting > >>> to be triggered by other peoples' non-stock configurations? We've > >> … > >> > >> I'd like to report one, most likely an upstream problem: > >> > >> 'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS > >> names. > >> A line like > >> "restrict time1 nomodify nopeer noquery notrap" > >> results in: > >> ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1 > >> ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7 > >> > >> I've always been using unqualified hostnames with 'restrict', and since > >> defining 'server' with unqualified hostname still works, this seems to be > >> a significant bug to me. People are forced to change 'restrict' > >> definitions, but not to also change other unqualified definitions, which > >> potentially leads to misconfigurations, since intentionally matching > >> definitions can now differ easily. > >> > >> Has anybody already noticed this problem? And any idea if upstream is > >> aware? > > I had a quick look at this today. It appears that the problem isn't > > unqualified names exactly, but rather an unqualified name that exactly > > matches an ntp.conf keyword will be mistaken by the ntpd config parser > > as a misplaced keyword token. So most unqualified names should work, > > but there are about 200 words that won't, many of them very sensible > > names for ntp servers such as "ntp" and "time1" and "time2". > > > > When I look at the ntp_parser.y grammar file it's not clear to me why > > "server time1" works and "restrict time1" doesn't. I couldn't find any > > way to trick it into taking a keyword as a hostname following restrict > > (like using quotes). > > Thank you very much! This is very interesting and exactly matches my > tested host names. > I wish I had better C skills to find such things myself. Out of > curiosity: How much time took it to find the ntp_parser.y route? (and > with what “IDE” I'm stuck with vim) > > One additional observation was that the reserved-name-collision only > happens with CNAME records. > I hope I'll find some time to actually do look into sources - which I > didn't at first hand because of my lousy C skills :-( But that's the > place where to find hints :-) > > Thanks, > I started out pretty sure what I was going to discover, based on the error you reported "syntax error, unexpected T_Time1". That 'T_Time1' just said to me "that's a yacc/bison token constant, this is going to be an error in their grammar (.y) file". The tricky part is that the .y file isn't in the base source code, I had to go find it in the vendor branch. I don't think the CNAME part matters. I tried changing my 'ntp' CNAME to a regular A record and the error still happens if I use it as an unqualified name with restrict. The IDE I use is SlickEdit, running on freebsd under the linuxulator. It's a commercial product worth every penny I've paid for various versions since the 90s. It gets the credit for a lot of my productivity. -- Ian ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
On 21 August 2015 at 09:06, Eugene M. Zheganin wrote: > Hi. > > On 20.08.2015 14:51, Damien Fleuriot wrote: > > > > Hello list, > > > > > > > > We've managed to find the source of the bug, if it is indeed a bug. > > > > It all comes down to the order in which the IP addresses are assigned to > > the interface from /etc/rc.conf. > > > > > > When using the following syntax, the physical IP address is configured > > AFTER the CARPs on the interface, which results in the CARP > advertisements > > being sourced from the CARP IP, triggering the double MASTER situation : > > ipv4_addrs_int="1.2.3.4/24" > > ifconfig_int_alias0="1.2.3.6/32 vhid 1 pass test advskew 20" > > > > When using either of the following syntaxes, the physical IP address is > > configured BEFORE the CARPs, which results in the CARP advertisements > being > > sourced from the physical IP and restoring normal functionality : > > ifconfig_int="inet 1.2.3.4/24" > > ifconfig_int_alias0="1.2.3.6/32 vhid 1 pass test advskew 20" > > OR > > ifconfig_int_alias0="1.2.3.4/24" > > ifconfig_int_alias1="1.2.3.6/32 vhid 1 pass test advskew 20" > > > It has been there since carp-ng was commited to the 10-CURRENT 2 years > ago. The thing is, carp-ng doesn't need a non-carp address on an > interface anymore, both nodes can work fine using only shared address. > This isn't comfortable in lots of cases, but still. Thus, kernel sends > carp advertisements from a primary address on the interface (which is > normal behavior for any known network stack) and for FreeBSD that > primary address has always been the first address on an interface for a > given AF. Thus, your split-brain carp situation cause lies definitely > somewhere else. I'm running carp on FreeBSD for years, including legacy > one; if there is a bug - the situation you are describing probably isn't > one. > > Eugene, agree to disagree here. I've also been using CARP for years, both legacy and carp-ng, and while I'm not an expert on its inner workings I do understand how it operates. What you describe WRT the network stack and sourcing the advertisements is correct, I'll give you that. The problem lies not with CARP but with how the IP addresses are assigned by rc.conf It is abnormal that the CARP addresses should be set up first, when using the "ipv4_addrs_int" syntax. Therein lies the problem. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vmx and esxi vst mode vlan tagging
On Fri, 21 Aug 2015 12:41:02 +0300 Slawa Olhovchenkov wrote: > On Fri, Aug 21, 2015 at 10:25:05AM +0200, Marko Cupa'c wrote: > > > On Thu, 20 Aug 2015 13:23:53 +0200 > > Marko Cupa'c wrote: > > > > > Hi, > > > > > > I have just spent half an hour bashing my head against the wall > > > why my FreeBSD-10.2-RELEASE i386 machine with kernel-included vmx > > > driver and emulators/open-vm-tools installed won't ping machines > > > on the other vlan on the same vSwitch. It DOES ping other virtual > > > machines on the same vSwitch and same vlan (freebsd servers), and > > > it DOES ping physical machines in other vlans. It DOES NOT ping > > > virtual machines on the same vSwitch and different vlan (windows > > > servers). > > > > > > To cut the long story short, it appears that the problem is on > > > FreeBSD side, as another machine (FreeBSD-10.1-RELEASE-p14 amd > > > 64) with vmx3f0 driver and VMWare's vmware-tools installed pings > > > everything as it should. > > > > > > Could it be that FreeBSD's vmx driver does not support all the > > > functions of vmware's vmx3f driver? > > > > I deleted open-vm-tools and installed vmware-tools, but the broblem > > remains. I'm gonna test if 10.2-RELEASE amd64 has the same issue. > > That should tell me if problem is related to difference between > > i386 and amd64 in 10.2-RELEASE. If not, could this be a regression > > in 10.2? > > > > Should I report a bug or do some more testing? > > netstat -nr > arp -na > ifconfig -a > ping's commands and results. Sorry guys, please dismiss this issue entirely. I was constantly setting /24 subnet mask whereas the correct mask for the vlan is /27. Please consider the fact that my long-needed vacation starts tomorrow :) Regards, -- Marko Cupać https://www.mimar.rs/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vmx and esxi vst mode vlan tagging
On Fri, Aug 21, 2015 at 10:25:05AM +0200, Marko Cupa'c wrote: > On Thu, 20 Aug 2015 13:23:53 +0200 > Marko Cupa'c wrote: > > > Hi, > > > > I have just spent half an hour bashing my head against the wall why my > > FreeBSD-10.2-RELEASE i386 machine with kernel-included vmx driver and > > emulators/open-vm-tools installed won't ping machines on the other > > vlan on the same vSwitch. It DOES ping other virtual machines on the > > same vSwitch and same vlan (freebsd servers), and it DOES ping > > physical machines in other vlans. It DOES NOT ping virtual machines > > on the same vSwitch and different vlan (windows servers). > > > > To cut the long story short, it appears that the problem is on FreeBSD > > side, as another machine (FreeBSD-10.1-RELEASE-p14 amd 64) with vmx3f0 > > driver and VMWare's vmware-tools installed pings everything as it > > should. > > > > Could it be that FreeBSD's vmx driver does not support all the > > functions of vmware's vmx3f driver? > > I deleted open-vm-tools and installed vmware-tools, but the broblem > remains. I'm gonna test if 10.2-RELEASE amd64 has the same issue. That > should tell me if problem is related to difference between i386 and > amd64 in 10.2-RELEASE. If not, could this be a regression in 10.2? > > Should I report a bug or do some more testing? netstat -nr arp -na ifconfig -a ping's commands and results. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: vmx and esxi vst mode vlan tagging
On Thu, 20 Aug 2015 13:23:53 +0200 Marko Cupać wrote: > Hi, > > I have just spent half an hour bashing my head against the wall why my > FreeBSD-10.2-RELEASE i386 machine with kernel-included vmx driver and > emulators/open-vm-tools installed won't ping machines on the other > vlan on the same vSwitch. It DOES ping other virtual machines on the > same vSwitch and same vlan (freebsd servers), and it DOES ping > physical machines in other vlans. It DOES NOT ping virtual machines > on the same vSwitch and different vlan (windows servers). > > To cut the long story short, it appears that the problem is on FreeBSD > side, as another machine (FreeBSD-10.1-RELEASE-p14 amd 64) with vmx3f0 > driver and VMWare's vmware-tools installed pings everything as it > should. > > Could it be that FreeBSD's vmx driver does not support all the > functions of vmware's vmx3f driver? I deleted open-vm-tools and installed vmware-tools, but the broblem remains. I'm gonna test if 10.2-RELEASE amd64 has the same issue. That should tell me if problem is related to difference between i386 and amd64 in 10.2-RELEASE. If not, could this be a regression in 10.2? Should I report a bug or do some more testing? Thank you in advance, -- Marko Cupać https://www.mimar.rs/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
Hi. On 20.08.2015 14:51, Damien Fleuriot wrote: > > Hello list, > > > > We've managed to find the source of the bug, if it is indeed a bug. > > It all comes down to the order in which the IP addresses are assigned to > the interface from /etc/rc.conf. > > > When using the following syntax, the physical IP address is configured > AFTER the CARPs on the interface, which results in the CARP advertisements > being sourced from the CARP IP, triggering the double MASTER situation : > ipv4_addrs_int="1.2.3.4/24" > ifconfig_int_alias0="1.2.3.6/32 vhid 1 pass test advskew 20" > > When using either of the following syntaxes, the physical IP address is > configured BEFORE the CARPs, which results in the CARP advertisements being > sourced from the physical IP and restoring normal functionality : > ifconfig_int="inet 1.2.3.4/24" > ifconfig_int_alias0="1.2.3.6/32 vhid 1 pass test advskew 20" > OR > ifconfig_int_alias0="1.2.3.4/24" > ifconfig_int_alias1="1.2.3.6/32 vhid 1 pass test advskew 20" > It has been there since carp-ng was commited to the 10-CURRENT 2 years ago. The thing is, carp-ng doesn't need a non-carp address on an interface anymore, both nodes can work fine using only shared address. This isn't comfortable in lots of cases, but still. Thus, kernel sends carp advertisements from a primary address on the interface (which is normal behavior for any known network stack) and for FreeBSD that primary address has always been the first address on an interface for a given AF. Thus, your split-brain carp situation cause lies definitely somewhere else. I'm running carp on FreeBSD for years, including legacy one; if there is a bug - the situation you are describing probably isn't one. Eugene. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
