Should I be using ipv6_activate_all_interfaces or ip6addrctl_policy=ipv6_prefer
Hello, I am configuring a server with IPv4 and IPv6 addresses and have noticed that FreeBSD seems to be preferring IPv4, such as when establishing SSH connections. After reading through /etc/defaults/rc.conf, and later /etc/rc.d/ip6addrctl I have come to the conclusion that I have two ways to tell FreeBSD to prefer IPv6: 1) Add ipv6_activate_all_interfaces to /etc/rc.conf 2) Add ip6addrctl_policy=ipv6_prefer to /etc/rc.conf Could anybody with a little more knowledge on the matter explain to me which of the two options is more preferential? If it helps, I only have a single NIC in the server, and it does not function as a gateway. Thanks, Jonathan. (I do apologise if this email ends up being sent as HTML. I haven't tried sending plaintext from this particular webmail client before). ___ 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
[Bug 192426] [bpf] [panic] [patch]: Kernel panic when using BPF
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192426 Robert Clipsham rob...@octarineparrot.com changed: What|Removed |Added Summary|[bpf] [panic]: Kernel panic |[bpf] [panic] [patch]: |when using BPF |Kernel panic when using BPF -- You are receiving this mail because: You are the assignee for the bug. ___ 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
[Bug 191975] [ng_iface] [regression] in 10.0: cannot contact local services
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191975 Gleb Smirnoff gleb...@freebsd.org changed: What|Removed |Added CC||gleb...@freebsd.org --- Comment #5 from Gleb Smirnoff gleb...@freebsd.org --- This looks more like a pf issue, not ng_iface. -- You are receiving this mail because: You are the assignee for the bug. ___ 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
[RFC] PLPMTU Blackhole Detection
https://reviews.freebsd.org/D506 This patch implements an attempt to adjust the MTU/MSS of a connection to work around poor networks that block ICMP fragmentation needed indications. sean p.s. I intend on working on a full PLPMTU implementation after working this into the tree. ___ 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: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00
Hi, the newcwv patch is probably stale now with Tom Jones' recent patch based on a more up-to-date version of the Internet-Draft, but the PRR patch should still be useful? Lars On 2014-6-19, at 23:35, George Neville-Neil g...@neville-neil.com wrote: On 4 Feb 2014, at 1:38, Eggert, Lars wrote: Hi, below are two patches that implement RFC6937 (Proportional Rate Reduction for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP to support Rate-Limited Traffic). They were done by Aris Angelogiannopoulos for his MS thesis, which is at https://eggert.org/students/angelogiannopoulos-thesis.pdf. The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry for the delay in sending them, we'd been trying to get some feedback from committers first, without luck.) Please note that newcwv is still a work in progress in the IETF, and the patch has some limitations with regards to the pipeACK Sampling Period mentioned in the Internet-Draft. Aris says this in his thesis about what exactly he implemented: The second implementation choice, is in regards with the measurement of pipeACK. This variable is the most important introduced by the method and is used to compute the phase that the sender currently lies in. In order to compute pipeACK the approach suggested by the Internet Draft (ID) is followed [ncwv]. During initialization, pipeACK is set to the maximum possible value. A helper variable prevHighACK is introduced that is initialized to the initial sequence number (iss). prevHighACK holds the value of the highest acknowledged byte so far. pipeACK is measured once per RTT meaning that when an ACK covering prevHighACK is received, pipeACK becomes the difference between the current ACK and prevHighACK. This is called a pipeACK sample. A newer version of the draft suggests that multiple pipeACK samples can be used during the pipeACK sampling period. Lars [prr.patch] [newcwv.patch] Apologies for not looking at this as yet. It is now closer to the top of my list. Best, George signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00
On Tue, Aug 26, 2014 at 02:43:49PM +, Eggert, Lars wrote: Hi, the newcwv patch is probably stale now with Tom Jones' recent patch based on a more up-to-date version of the Internet-Draft, but the PRR patch should still be useful? My newcwv patch is much more up to date than Aris's, but it is slightly different in implementation. I have had a few suggestions from Adrian, but he couldn't comment on how it relates to the tcp internals. There is a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 The biggest difference in structure between mine and Aris's patch is the use of tcp timers. It would be good to hear if my approach or Aris's is prefered. On 2014-6-19, at 23:35, George Neville-Neil g...@neville-neil.com wrote: On 4 Feb 2014, at 1:38, Eggert, Lars wrote: Hi, below are two patches that implement RFC6937 (Proportional Rate Reduction for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP to support Rate-Limited Traffic). They were done by Aris Angelogiannopoulos for his MS thesis, which is at https://eggert.org/students/angelogiannopoulos-thesis.pdf. The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry for the delay in sending them, we'd been trying to get some feedback from committers first, without luck.) Please note that newcwv is still a work in progress in the IETF, and the patch has some limitations with regards to the pipeACK Sampling Period mentioned in the Internet-Draft. Aris says this in his thesis about what exactly he implemented: The second implementation choice, is in regards with the measurement of pipeACK. This variable is the most important introduced by the method and is used to compute the phase that the sender currently lies in. In order to compute pipeACK the approach suggested by the Internet Draft (ID) is followed [ncwv]. During initialization, pipeACK is set to the maximum possible value. A helper variable prevHighACK is introduced that is initialized to the initial sequence number (iss). prevHighACK holds the value of the highest acknowledged byte so far. pipeACK is measured once per RTT meaning that when an ACK covering prevHighACK is received, pipeACK becomes the difference between the current ACK and prevHighACK. This is called a pipeACK sample. A newer version of the draft suggests that multiple pipeACK samples can be used during the pipeACK sampling period. Lars [prr.patch] [newcwv.patch] Apologies for not looking at this as yet. It is now closer to the top of my list. Best, George -- Tom @adventureloop adventurist.me :wq ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? -- John Baldwin ___ 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
9.3 RELEASE not forwarding pkt-gen (netmap) packets over XenServer
Hello list, I am using FreeBSD 9.3 RELEASE over XenServer 6.2 with a quad port Intel NIC dedicated to my tests. I have three virtual machines, all using NICs with PCI passthrough, in this way: One VM (vm0) as router between the others, with two Intel NIC. Stock kernel. One VM (vm1) as generator, with one Intel NIC. netmap + XEMHVM kernel. One VM (vm2) as consumer, with one Intel NIC. netmap + XEMHVM kernel. When I connect vm1 to vm2 directly, traffic flows without problem, no matter how I select the source an destination IP and MAC addresses. When I connect through vm0, just enabling IP forwarding and no packet filter active (i.e., no PF compiled in and no ipfw module loaded), vm2 can consume all the traffic, but only if I specify only one source and only one destination IP addresses. With this in vm1: pkt-gen -i igb0 -f tx -s 10.0.0.1 -d 192.168.10.1 \ -S igb0 real MAC -D router igb -R 10 And this in vm2: pkt-gen -i igb0 -f rx Setting up static ARP table and route table entries in vm0 for vm1 and vm2, I can see 100Kpps on vm2. But only changing in vm1 -d 192.168.10.1-192.168.10.2 I can only see 50Kpps going out to vm2 (with tcpdump inside vm0, where I have stock kernel), but 100Kpps coming from vm1. If I designate a range of four destination addresses, I get 1/4 of the total designated rate going to vm2, even with all the packets getting to vm0 from vm1. Does not matter at all the packet rate I set, the division continues to occur. What could be wrong? In vm0: Routes: 192.168.10/24 gateway 192.168.2.2 192.168.11/24 gateway 192.168.2.2 10/8 gateway 192.168.1.1 ARP static: 192.168.2.2 MAC from igb0 of vm2 192.168.1.1 MAC from igb0 of vm1 Thank you for your attention! Raimundo Santos ___ 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: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00
Hi! I'm going to merge Tom's work in a week unless someone gives me a really good reason not to. I think there's been enough work and discussion about it since the first post from Lars in Feburary and enough review opportunity. -a On 26 August 2014 07:55, Tom Jones jo...@sdf.org wrote: On Tue, Aug 26, 2014 at 02:43:49PM +, Eggert, Lars wrote: Hi, the newcwv patch is probably stale now with Tom Jones' recent patch based on a more up-to-date version of the Internet-Draft, but the PRR patch should still be useful? My newcwv patch is much more up to date than Aris's, but it is slightly different in implementation. I have had a few suggestions from Adrian, but he couldn't comment on how it relates to the tcp internals. There is a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520 The biggest difference in structure between mine and Aris's patch is the use of tcp timers. It would be good to hear if my approach or Aris's is prefered. On 2014-6-19, at 23:35, George Neville-Neil g...@neville-neil.com wrote: On 4 Feb 2014, at 1:38, Eggert, Lars wrote: Hi, below are two patches that implement RFC6937 (Proportional Rate Reduction for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP to support Rate-Limited Traffic). They were done by Aris Angelogiannopoulos for his MS thesis, which is at https://eggert.org/students/angelogiannopoulos-thesis.pdf. The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry for the delay in sending them, we'd been trying to get some feedback from committers first, without luck.) Please note that newcwv is still a work in progress in the IETF, and the patch has some limitations with regards to the pipeACK Sampling Period mentioned in the Internet-Draft. Aris says this in his thesis about what exactly he implemented: The second implementation choice, is in regards with the measurement of pipeACK. This variable is the most important introduced by the method and is used to compute the phase that the sender currently lies in. In order to compute pipeACK the approach suggested by the Internet Draft (ID) is followed [ncwv]. During initialization, pipeACK is set to the maximum possible value. A helper variable prevHighACK is introduced that is initialized to the initial sequence number (iss). prevHighACK holds the value of the highest acknowledged byte so far. pipeACK is measured once per RTT meaning that when an ACK covering prevHighACK is received, pipeACK becomes the difference between the current ACK and prevHighACK. This is called a pipeACK sample. A newer version of the draft suggests that multiple pipeACK samples can be used during the pipeACK sampling period. Lars [prr.patch] [newcwv.patch] Apologies for not looking at this as yet. It is now closer to the top of my list. Best, George -- Tom @adventureloop adventurist.me :wq ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) -- John Baldwin ___ 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: 9.3 RELEASE not forwarding pkt-gen (netmap) packets over XenServer
That is what a tcpdump says (in vm0, the router): 15:38:13.286112 00:1b:21:53:51:3d 00:1b:21:53:51:39, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46) 10.0.0.1.0 192.168.10.1.0: [udp sum ok] UDP, length 18 15:38:13.286119 00:1b:21:53:51:3d 00:1b:21:53:51:39, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 6605 (-6604)!) 10.0.0.1.0 192.168.10.2.0: [bad udp cksum 0x5e7c - 0x5e7b!] UDP, length 18 All of these with txcsum, rxcsum and tso4 disabled. I am trying to test the performance of this virtual router in using dummynet to shape by IP and pkt-gen, with its said ability to generate packets with ranges of IP sources, could be a very good traffic generator. Once again, thank you! Raimundo Santos ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 ___ 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
New message from SoundCloud PR
[letter.png] Hey, [1]SoundCloudPR sent you a message: The SoundCloud Promotional Service offers Artists, DJ's, Singers and Managers a simple, cost-effective way to reach targeted followers, sales, comments, plays and downloads on SoundCloud. We target like-minded users who are interested in your new tracks, releases and sets. Artists that generate a lot of honest consistent feedbacks and traffic to their profiles are the ones who stand out from the crowd. To check this new service, go directly to the [2]SoundCloud Promotion Page [1eCW8gV] [3]SoundCloudPR [4]Promote your account [5]Unsubscribe References Visible links 1. http://bit.ly/scpromo 2. http://bit.ly/scpromo 3. http://bit.ly/scpromo 4. http://bit.ly/scpromo 5. mailto:soundcloud...@outlook.com?subject=NOMORE Hidden links: 7. http://bit.ly/scpromo ___ 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
ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included)
Hello,
I am trying to get the ixgbe driver + PF/ALTQ working under stable/9.
Initially, loading a PF rulset with ALTQ enabled fails on an ix interface,
reporting ix0: driver does not support altq. This is similar to the
behavior over the last few years when dealing with the igb driver. However,
I have been using ALTQ + igb with great success by defining IGB_LEGACY_TX
in the e1000/igb driver code. I noticed that ixgbe has a similar define
IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior,
that also enables ALTQ support.
After adding the IXGBE_LEGACY_TX define to ixgbe source, building the
driver fails with the following compile errors:
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que':
/usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '-'
(have 'struct ifaltq')
/usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '-'
(have 'struct ifaltq')
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer':
/usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no member
named 'txq_task'
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_free_transmit_buffers':
/usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no member
named 'br'
/usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no member
named 'br'
So it seems that the IXGBE_LEGACY_TX path no longer compiles successfully,
and perhaps never did? Using e1000 as a reference, fixing the pointer
error, and looking at previous revisions of ixgbe.c, I was able to come up
with the following patch that got the driver to compile while having
IXGBE_LEGACY_TX defined. Note that the following svn diff is against HEAD,
which as far as I can tell contains the same broken IXGBE_LEGACY_TX path as
stable/9 and stable/10.
Index: ixgbe.c
===
--- ixgbe.c (revision 270665)
+++ ixgbe.c (working copy)
@@ -1543,7 +1543,7 @@
IXGBE_TX_LOCK(txr);
ixgbe_txeof(txr);
#ifdef IXGBE_LEGACY_TX
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
+ if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
ixgbe_start_locked(txr, ifp);
#else
if (!drbr_empty(ifp, txr-br))
@@ -2091,7 +2091,11 @@
(paused == 0))
++hung;
else if (txr-queue_status == IXGBE_QUEUE_WORKING)
+#ifndef IXGBE_LEGACY_TX
taskqueue_enqueue(que-tq, txr-txq_task);
+#else
+ taskqueue_enqueue(que-tq, que-que_task);
+#endif
}
/* Only truely watchdog if all queues show hung */
if (hung == adapter-num_queues)
@@ -3327,10 +3331,6 @@
tx_buffer-map = NULL;
}
}
-#ifdef IXGBE_LEGACY_TX
- if (txr-br != NULL)
- buf_ring_free(txr-br, M_DEVBUF);
-#endif
if (txr-tx_buffers != NULL) {
free(txr-tx_buffers, M_DEVBUF);
txr-tx_buffers = NULL;
===
Using a stable/9 kernel with the above patch allowed me to load my PF
ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I no
longer received the driver does not support altq error. Queueing on the
ix interface now appears to work as it should.
I am hoping someone can help verify my work and perhaps audit and correct
the IXGBE_LEGACY_TX path currently in the svn tree.
Also, FWIW, here is relevant pciconf output for the ixbge card.
ix0@pci0:1:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 0023fa300715
ecap 000e[150] = unknown 1
ecap 0010[160] = unknown 1
ix1@pci0:1:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 0023fa300715
ecap 000e[150] = unknown 1
ecap 0010[160] = unknown 1
Thanks!
-Nick
___
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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston ma...@freebsd.org wrote: On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 BTW, is it just me, or is arcanist insanely slow? Usually arc diff --create or arc diff --update take many minutes to complete. Like, 30 minutes. I've been trying to do arc patch for nearly an hour now, but it hasn't completed yet. ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
On 26 August 2014 14:22, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:51 PM, Mark Johnston ma...@freebsd.org wrote: On Tue, Aug 26, 2014 at 03:15:31PM -0400, John Baldwin wrote: On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote: On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin j...@freebsd.org wrote: On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote: Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? A fix has to make into HEAD first. I've cc'd Alan who responded to the bug. Alan, note that glebius@ already committed the test case to HEAD a while ago. First, Gleb's testcase needs to be converted to ATF. This would be a good exercise for anybody who's new to ATF and wants some practice. Anybody interested? While that would be nice, I don't know that it's quite fair to require the test to be converted before working on a possible fix. The existing test doesn't seem that hard to run by hand: % cd work/freebsd/head/tools/regression/sockets/unix_passfd/ % make ... % ./unix_passfd beginning test1-simplesendfd test1-simplesendfd passed ... beginning test8-rigths+creds+payload unix_passfd: test8-rigths+creds+payload: recvmsg: 24 bytes received I only say this because in the bug followup you seemed to have described a possible solution so it seems that you would be able to develop a fix quicker than other folks since you are already familiar with the issues involved. (Also, you've fixed other related issues recently.) As it happens, I went ahead and did this anyway: https://reviews.freebsd.org/D689 BTW, is it just me, or is arcanist insanely slow? Usually arc diff --create or arc diff --update take many minutes to complete. Like, 30 minutes. I've been trying to do arc patch for nearly an hour now, but it hasn't completed yet. It's you. it's very quick for me. -a ___ 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: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included)
Hi,
I'm not surprised the legacy tx path has bitrotted there.
Please file a bug with this - https://bugs.freebsd.org/submit/ - and
then just keep poking people until it's done.
Thank!
-a
On 26 August 2014 13:42, Nick Rogers ncrog...@gmail.com wrote:
Hello,
I am trying to get the ixgbe driver + PF/ALTQ working under stable/9.
Initially, loading a PF rulset with ALTQ enabled fails on an ix interface,
reporting ix0: driver does not support altq. This is similar to the
behavior over the last few years when dealing with the igb driver. However,
I have been using ALTQ + igb with great success by defining IGB_LEGACY_TX
in the e1000/igb driver code. I noticed that ixgbe has a similar define
IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior,
that also enables ALTQ support.
After adding the IXGBE_LEGACY_TX define to ixgbe source, building the
driver fails with the following compile errors:
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que':
/usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '-'
(have 'struct ifaltq')
/usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '-'
(have 'struct ifaltq')
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer':
/usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no member
named 'txq_task'
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_free_transmit_buffers':
/usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no member
named 'br'
/usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no member
named 'br'
So it seems that the IXGBE_LEGACY_TX path no longer compiles successfully,
and perhaps never did? Using e1000 as a reference, fixing the pointer
error, and looking at previous revisions of ixgbe.c, I was able to come up
with the following patch that got the driver to compile while having
IXGBE_LEGACY_TX defined. Note that the following svn diff is against HEAD,
which as far as I can tell contains the same broken IXGBE_LEGACY_TX path as
stable/9 and stable/10.
Index: ixgbe.c
===
--- ixgbe.c (revision 270665)
+++ ixgbe.c (working copy)
@@ -1543,7 +1543,7 @@
IXGBE_TX_LOCK(txr);
ixgbe_txeof(txr);
#ifdef IXGBE_LEGACY_TX
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
+ if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
ixgbe_start_locked(txr, ifp);
#else
if (!drbr_empty(ifp, txr-br))
@@ -2091,7 +2091,11 @@
(paused == 0))
++hung;
else if (txr-queue_status == IXGBE_QUEUE_WORKING)
+#ifndef IXGBE_LEGACY_TX
taskqueue_enqueue(que-tq, txr-txq_task);
+#else
+ taskqueue_enqueue(que-tq, que-que_task);
+#endif
}
/* Only truely watchdog if all queues show hung */
if (hung == adapter-num_queues)
@@ -3327,10 +3331,6 @@
tx_buffer-map = NULL;
}
}
-#ifdef IXGBE_LEGACY_TX
- if (txr-br != NULL)
- buf_ring_free(txr-br, M_DEVBUF);
-#endif
if (txr-tx_buffers != NULL) {
free(txr-tx_buffers, M_DEVBUF);
txr-tx_buffers = NULL;
===
Using a stable/9 kernel with the above patch allowed me to load my PF
ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I no
longer received the driver does not support altq error. Queueing on the
ix interface now appears to work as it should.
I am hoping someone can help verify my work and perhaps audit and correct
the IXGBE_LEGACY_TX path currently in the svn tree.
Also, FWIW, here is relevant pciconf output for the ixbge card.
ix0@pci0:1:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 0023fa300715
ecap 000e[150] = unknown 1
ecap 0010[160] = unknown 1
ix1@pci0:1:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 0023fa300715
ecap 000e[150] = unknown 1
ecap 0010[160] = unknown 1
Thanks!
-Nick
___
freebsd-net@freebsd.org mailing
Re: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included)
On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd adr...@freebsd.org wrote:
Hi,
I'm not surprised the legacy tx path has bitrotted there.
Please file a bug with this - https://bugs.freebsd.org/submit/ - and
then just keep poking people until it's done.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053
Thank!
-a
On 26 August 2014 13:42, Nick Rogers ncrog...@gmail.com wrote:
Hello,
I am trying to get the ixgbe driver + PF/ALTQ working under stable/9.
Initially, loading a PF rulset with ALTQ enabled fails on an ix
interface,
reporting ix0: driver does not support altq. This is similar to the
behavior over the last few years when dealing with the igb driver.
However,
I have been using ALTQ + igb with great success by defining IGB_LEGACY_TX
in the e1000/igb driver code. I noticed that ixgbe has a similar define
IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior,
that also enables ALTQ support.
After adding the IXGBE_LEGACY_TX define to ixgbe source, building the
driver fails with the following compile errors:
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que':
/usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '-'
(have 'struct ifaltq')
/usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of '-'
(have 'struct ifaltq')
/usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer':
/usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no
member
named 'txq_task'
/usr/src/sys/dev/ixgbe/ixgbe.c: In function
'ixgbe_free_transmit_buffers':
/usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no
member
named 'br'
/usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no
member
named 'br'
So it seems that the IXGBE_LEGACY_TX path no longer compiles
successfully,
and perhaps never did? Using e1000 as a reference, fixing the pointer
error, and looking at previous revisions of ixgbe.c, I was able to come
up
with the following patch that got the driver to compile while having
IXGBE_LEGACY_TX defined. Note that the following svn diff is against
HEAD,
which as far as I can tell contains the same broken IXGBE_LEGACY_TX path
as
stable/9 and stable/10.
Index: ixgbe.c
===
--- ixgbe.c (revision 270665)
+++ ixgbe.c (working copy)
@@ -1543,7 +1543,7 @@
IXGBE_TX_LOCK(txr);
ixgbe_txeof(txr);
#ifdef IXGBE_LEGACY_TX
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
+ if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
ixgbe_start_locked(txr, ifp);
#else
if (!drbr_empty(ifp, txr-br))
@@ -2091,7 +2091,11 @@
(paused == 0))
++hung;
else if (txr-queue_status == IXGBE_QUEUE_WORKING)
+#ifndef IXGBE_LEGACY_TX
taskqueue_enqueue(que-tq, txr-txq_task);
+#else
+ taskqueue_enqueue(que-tq, que-que_task);
+#endif
}
/* Only truely watchdog if all queues show hung */
if (hung == adapter-num_queues)
@@ -3327,10 +3331,6 @@
tx_buffer-map = NULL;
}
}
-#ifdef IXGBE_LEGACY_TX
- if (txr-br != NULL)
- buf_ring_free(txr-br, M_DEVBUF);
-#endif
if (txr-tx_buffers != NULL) {
free(txr-tx_buffers, M_DEVBUF);
txr-tx_buffers = NULL;
===
Using a stable/9 kernel with the above patch allowed me to load my PF
ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I no
longer received the driver does not support altq error. Queueing on the
ix interface now appears to work as it should.
I am hoping someone can help verify my work and perhaps audit and correct
the IXGBE_LEGACY_TX path currently in the svn tree.
Also, FWIW, here is relevant pciconf output for the ixbge card.
ix0@pci0:1:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 0023fa300715
ecap 000e[150] = unknown 1
ecap 0010[160] = unknown 1
ix1@pci0:1:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link
Re: 9.3 RELEASE not forwarding pkt-gen (netmap) packets over XenServer
On Tue, Aug 26, 2014 at 9:35 PM, Raimundo Santos rait...@gmail.com wrote: 15:38:13.286119 00:1b:21:53:51:3d 00:1b:21:53:51:39, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 6605 (-6604)!) 10.0.0.1.0 192.168.10.2.0: [bad udp cksum 0x5e7c - 0x5e7b!] UDP, length 18 Hi, the bad UDP checksum seems related to this pkt-gen bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187149 pkt-gen one checksum for all the paquets it generate (then once it update the IP or port, the checksum didn't match). Applying the patch correctly update the checksum for all paquets (but it have a performance impact). Regards, Olivier ___ 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
[Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 Hiren Panchasara hi...@freebsd.org changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ 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: Should I be using ipv6_activate_all_interfaces or ip6addrctl_policy=ipv6_prefer
On Tue, Aug 26, 2014 at 3:40 AM, free...@jonathanprice.org wrote: Hello, I am configuring a server with IPv4 and IPv6 addresses and have noticed that FreeBSD seems to be preferring IPv4, such as when establishing SSH connections. After reading through /etc/defaults/rc.conf, and later /etc/rc.d/ip6addrctl I have come to the conclusion that I have two ways to tell FreeBSD to prefer IPv6: 1) Add ipv6_activate_all_interfaces to /etc/rc.conf 2) Add ip6addrctl_policy=ipv6_prefer to /etc/rc.conf Could anybody with a little more knowledge on the matter explain to me which of the two options is more preferential? If it helps, I only have a single NIC in the server, and it does not function as a gateway. Thanks, Jonathan. Can you confirm that IPv6 is actually working between the systems in question? ping6 to it is a trivial test.Many issues can arise when trying ot get IPv6 running. Firewalls are a common issue. What output do you get from ip6addrctl show? netstat -rnf inet6? -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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
Re: Should I be using ipv6_activate_all_interfaces or ip6addrctl_policy=ipv6_prefer
On Tuesday 26 August 2014 10:40:27 free...@jonathanprice.org wrote: Hello, I am configuring a server with IPv4 and IPv6 addresses and have noticed that FreeBSD seems to be preferring IPv4, such as when establishing SSH connections. After reading through /etc/defaults/rc.conf, and later /etc/rc.d/ip6addrctl I have come to the conclusion that I have two ways to tell FreeBSD to prefer IPv6: 1) Add ipv6_activate_all_interfaces to /etc/rc.conf 2) Add ip6addrctl_policy=ipv6_prefer to /etc/rc.conf Could anybody with a little more knowledge on the matter explain to me which of the two options is more preferential? They both do different things. The activate knob is to enable ipv6 on an interface. To oversimplify it, if you configure an address on an interface, it is enabled. However, this switch enables this on all the rest of the interfaces, even the ones you didn't configure. ip6addrctl* affects things like hostname lookups to sort the addresses returned to the caller. They are different things entirely. I think you are expecting the behavior that ip6_prefer policy gives you. That's what we use in the freebsd.org cluster to have it use ipv6 where possible. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: 9.3 RELEASE not forwarding pkt-gen (netmap) packets over XenServer
On 26 August 2014 20:16, Olivier Cochard-Labbé oliv...@cochard.me wrote: On Tue, Aug 26, 2014 at 9:35 PM, Raimundo Santos rait...@gmail.com wrote: 15:38:13.286119 00:1b:21:53:51:3d 00:1b:21:53:51:39, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 6605 (-6604)!) 10.0.0.1.0 192.168.10.2.0: [bad udp cksum 0x5e7c - 0x5e7b!] UDP, length 18 Hi, the bad UDP checksum seems related to this pkt-gen bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187149 Hello Olivier, thank you for pointing it out. That patch help me to achieve my needs. pkt-gen one checksum for all the paquets it generate (then once it update the IP or port, the checksum didn't match). Applying the patch correctly update the checksum for all paquets (but it have a performance impact). As my needs are somehow low, I can not notice any performance penalty. Cheers, Raimundo Santos ___ 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
