freebsd-net Digest, Vol 365, Issue 6
freebsd-n...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-net
or, via email, send a message with subject or body 'help' to
freebsd-n...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-net digest..."
Today's Topics:
1. Re: Is this correct? (Bjoern A. Zeeb)
2. Re: Is this correct? (Ermal Lu?i)
3. Re: Is this correct? (Bjoern A. Zeeb)
4. Re: kern/140597 implement Lost Retransmission Detection
(Scheffenegger, Richard)
5. Re: kern/144917: Flowtable crashes system (K. Macy)
6. Re: Un-obsolete'ing ipv6_enable (Doug Barton)
7. Re: bridged wlan/ether still the same (Stefan Bethke)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Apr 2010 17:11:15 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>
Subject: Re: Is this correct?
To: Ermal Lu?i <ermal...@gmail.com>
Cc: freebsd-net <freeb...@freebsd.org>
Message-ID: <2010040217...@maildrop.int.zabbadoz.net>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, 19 Mar 2010, Ermal Luçi wrote:
Hi,
> Shouldn't this check be
> if (m->m_len > sizeof (struct ip)) {
> instead of
> if (m->m_len < sizeof (struct ip)) {
Should it be > or >= ?
/bz
--
Bjoern A. Zeeb It will not break if you know what you are doing.
------------------------------
Message: 2
Date: Fri, 2 Apr 2010 19:29:11 +0200
From: Ermal Lu?i <ermal...@gmail.com>
Subject: Re: Is this correct?
To: "Bjoern A. Zeeb" <bzeeb...@lists.zabbadoz.net>
Cc: freebsd-net <freeb...@freebsd.org>
Message-ID:
<s2j9a542da31004021029u5...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 2, 2010 at 7:11 PM, Bjoern A. Zeeb
<bzeeb...@lists.zabbadoz.net> wrote:
> On Fri, 19 Mar 2010, Ermal Luçi wrote:
>
> Hi,
>
>> Shouldn't this check be
>> if (m->m_len > sizeof (struct ip)) {
>> instead of
>> if (m->m_len < sizeof (struct ip)) {
>
> Should it be > or >= ?
>
I would say >= since that is what logic assumes!
> /bz
>
> --
> Bjoern A. Zeeb It will not break if you know what you are doing.
--
Ermal
------------------------------
Message: 3
Date: Fri, 2 Apr 2010 17:40:58 +0000 (UTC)
From: "Bjoern A. Zeeb" <b...@FreeBSD.org>
Subject: Re: Is this correct?
To: Ermal Lu?i <ermal...@gmail.com>
Cc: freebsd-net <freeb...@freebsd.org>
Message-ID: <2010040217...@maildrop.int.zabbadoz.net>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, 2 Apr 2010, Ermal Luçi wrote:
Hi,
>>> Shouldn't this check be
>>> if (m->m_len > sizeof (struct ip)) {
>>> instead of
>>> if (m->m_len < sizeof (struct ip)) {
>>
>> Should it be > or >= ?
>>
> I would say >= since that is what logic assumes!
Yeah. Commit that.
/bz
--
Bjoern A. Zeeb It will not break if you know what you are doing.
------------------------------
Message: 4
Date: Fri, 2 Apr 2010 18:20:09 GMT
From: "Scheffenegger, Richard" <r...@netapp.com>
Subject: Re: kern/140597 implement Lost Retransmission Detection
To: freeb...@FreeBSD.org
Message-ID: <201004021820....@freefall.freebsd.org>
The following reply was made to PR kern/140597; it has been noted by GNATS.
From: "Scheffenegger, Richard" <r...@netapp.com>
To: <bug-fo...@freebsd.org>, "Lawrence Stewart" <last...@swin.edu.au>
Cc: "Biswas, Anumita" <Anumita...@netapp.com>
Subject: Re: kern/140597 implement Lost Retransmission Detection
Date: Fri, 2 Apr 2010 18:48:04 +0100
As discussed earlier, here is a simple fix.
Caveat: Doesn't work at the end of a session or when cwnd is very small
(<4 segments). Also, during heavy reordering, some spurious
re-retransmissions might occur (but that would only affect very few
re-retransmitted segments, as holes would still close with each
additional received SACK, reducing the chance of spurious
re-transmissions).=20
Benefit: during LAN burst drop events, TCP will not revert to
retransmission timeouts in order to recover. In a LAN, the RTO is
typically many orders of magnitude larger than the RTT. Not relying on
RTO whenever possible can help keep throughput up..
Simple Patch:
------------------------------------------
diff -u netinet.orig/tcp_output.c netinet/tcp_output.c
--- netinet.orig/tcp_output.c 2009-10-25 02:10:29.000000000 +0100
+++ netinet/tcp_output.c 2010-04-02 16:55:14.000000000 +0200
@@ -953,6 +953,10 @@
} else {
th->th_seq =3D htonl(p->rxmit);
p->rxmit +=3D len;
+ /* lost again detection */
+ if (SEQ_GEQ(p->rxmit, p->end)) {
+ p->rxmit =3D tp->snd_nxt;
+ }
tp->sackhint.sack_bytes_rexmit +=3D len;
}
th->th_ack =3D htonl(tp->rcv_nxt);
diff -u netinet.orig/tcp_sack.c netinet/tcp_sack.c
--- netinet.orig/tcp_sack.c 2009-10-25 02:10:29.000000000 +0100
+++ netinet/tcp_sack.c 2010-04-02 16:46:42.000000000 +0200
@@ -460,6 +460,13 @@
/* We must have at least one SACK hole in scoreboard. */
KASSERT(!TAILQ_EMPTY(&tp->snd_holes),
("SACK scoreboard must not be empty"));
+ /* lost again - then restart */
+ if ((temp =3D TAILQ_FIRST(&tp->snd_holes)) !=3D NULL) {
+ if (SEQ_GT(tp->snd_fack, temp->rxmit)) {
+ temp->rxmit =3D temp->start;
+ tp->sackhint.nexthole =3D temp;
+ }
+ }
cur =3D TAILQ_LAST(&tp->snd_holes, sackhole_head); /* Last SACK
hole. */
/*
* Since the incoming sack blocks are sorted, we can process
them
@@ -508,7 +515,9 @@
if (SEQ_GEQ(sblkp->end, cur->end)) {
/* Move end of hole backward. */
cur->end =3D sblkp->start;
- cur->rxmit =3D SEQ_MIN(cur->rxmit,
cur->end);
+ if (SEQ_GEQ(cur->rxmit, cur->end)) {
+ cur->rxmit =3D tp->snd_nxt;
+ }
} else {
/*
* ACKs some data in middle of a hole;
need
@@ -524,8 +533,9 @@
- temp->start);
}
cur->end =3D sblkp->start;
- cur->rxmit =3D =
SEQ_MIN(cur->rxmit,
- cur->end);
+ if (SEQ_GEQ(cur->rxmit,
cur->end)) {
+ cur->rxmit =3D
tp->snd_nxt;
+ }
}
}
}
------------------------------------------
Richard Scheffenegger
Field Escalation Engineer
NetApp Global Support=20
NetApp
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com <BLOCKED::http://www.netapp.com/> =20
Franz-Klein-Gasse 5
1190 Wien=20
------------------------------
Message: 5
Date: Fri, 2 Apr 2010 20:07:35 -0700
From: "K. Macy" <km...@freebsd.org>
Subject: Re: kern/144917: Flowtable crashes system
To: Ilya Zhuravlev <il...@el-crane.net>
Cc: freeb...@freebsd.org, Evgenii Davidov <da...@korolev-net.ru>
Message-ID:
<n2s82c4140e1004022007s2...@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R
Please try with the latest 8-STABLE and tell me if recent changes fix it.
Thanks,
Kip
On Thu, Mar 25, 2010 at 8:32 AM, Ilya Zhuravlev <il...@el-crane.net> wrote:
> On 21.03.2010 17:04, Evgenii Davidov wrote:
>>
>> úÄÒÁ×ÓÔ×ÕÊÔÅ,
>>
>> On Sat, Mar 20, 2010 at 11:06:35PM +0000, Doychin Dokov ÐÉÛÅÔ:
>>
>>>> Description:
>>>
>>> It seems like flowtable has been merged and enabled by default in 8.0....
>>> which is a really really bad idea.
>>> On a system which handles two full BGP tables it makes one of the CPU
>>> cores run at 100% right after most of the prefixes get installed in the
>>> routing table.
>>
>> i saw the same effect with ospf
>>
>
> 8.0-p2, 2 full-view with openbgpd
> "tuning":
> net.inet.tcp.blackhole=2
> net.inet.udp.blackhole=1
> net.inet.icmp.icmplim_output=0
> net.inet.icmp.drop_redirect=1
> net.inet.flowtable.nmbflows=32768
>
> 1 week uptime.Now I think only about increasing tx/rx descriptors to reduce
> interrupts (default values was not changed)
>
>
> netstat -w1 -Iigb0
> š š š š š šinput š š š š (igb0) š š š š š output
> š packets šerrs š š šbytes š špackets šerrs š š šbytes colls
> š š 49100 š š 0 š 12290513 š š š23693 š š 0 š 27268884 š š 0
> š š 48322 š š 0 š 12688283 š š š24332 š š 0 š 28099404 š š 0
> š š 50602 š š 0 š 12759620 š š š24437 š š 0 š 27698341 š š 0
> š š 47857 š š 0 š 11354124 š š š21410 š š 0 š 23845155 š š 0
>
> netstat -w1 -Iigb1
> š š š š š šinput š š š š (igb1) š š š š š output
> š packets šerrs š š šbytes š špackets šerrs š š šbytes colls
> š š 32428 š š 0 š 35027019 š š š24562 š š 0 š š5624934 š š 0
> š š 30621 š š 0 š 33384339 š š š23569 š š 0 š š4456944 š š 0
> š š 28419 š š 0 š 31014269 š š š21571 š š 0 š š3638083 š š 0
> š š 29409 š š 0 š 32524760 š š š22137 š š 0 š š3503600 š š 0
> š š 30965 š š 0 š 33532742 š š š23973 š š 0 š š5089231 š š 0
>
> netstat -w1 -Iem0
> š š š š š šinput š š š š š(em0) š š š š š output
> š packets šerrs š š šbytes š špackets šerrs š š šbytes colls
> š š 17217 š š 0 š š3929366 š š š72741 š š 0 š 46377762 š š 0
> š š 17412 š š 0 š š3745112 š š š75522 š š 0 š 49338883 š š 0
> š š 18385 š š 0 š š4014568 š š š77444 š š 0 š 50532101 š š 0
> š š 17142 š š 0 š š3875518 š š š77125 š š 0 š 47646681 š š 0
> š š 16870 š š 0 š š3528316 š š š73188 š š 0 š 47940959 š š 0
> š š 17069 š š 0 š š3682891 š š š80268 š š 0 š 52904747 š š 0
> š š 17313 š š 0 š š4101576 š š š75586 š š 0 š 51933330 š š 0
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
------------------------------
Message: 6
Date: Sat, 03 Apr 2010 00:42:10 -0700
From: Doug Barton <do...@FreeBSD.org>
Subject: Re: Un-obsolete'ing ipv6_enable
To: David Horn <dhor...@gmail.com>
Cc: freeb...@freebsd.org, Hiroki Sato <h...@freebsd.org>,
freeb...@freebsd.org
Message-ID: <4BB6F152...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
Sorry it's taken me so long to get back to this, had a lot of other
pressing issues. Short version, I think you're taking the wrong approach
here.
Longer version, I'm going to be posting to -current shortly to ask for
opinions on what the defaults should be. My understanding from the last
go-round about this topic was clear, but I'd like to confirm it. I have
a new, more complete patch at
http://people.freebsd.org/~dougb/v6-enable.diff that I'll be writing up
for that post. I'd like to request that we all follow up on that post
when it happens so that the conversation can all happen in the same
location, and with a wider audience.
More details below.
On 03/11/10 20:59, David Horn wrote:
> <snip> for brevity sake
>>> dh> Question 2) Assuming that people do desire consistency with allowing
>>> dh> for both a global, and a per-interface setting, do you agree with
>>> dh> having a global default for DHCPv4 (dhcpv4_default_enable), and for
>>> dh> IPv6 slaac/accept_rtadv (ipv6-slaac_default_enable), and the
>>> dh> per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
>>> dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
>>> dh> meta configuration variable.
I'm not interested in dealing with v4 dhcp as part of this, I want to
focus on getting v6 back to reasonable defaults. You should of course
feel free to pursue your ideas about v4 dhcp separately.
>>> I think the global configuration can be realized by setting something
>>> like ifconfig_DEFAULT_<proto>="AUTO" instead of adding a new global
>>> knobs.
Like I said, I'm hesitant to deal with v4 issues in this context. I'm
even more hesitant to deal with a global autoconf knob. The default v6
configuration is SLAAC, whereas in v4 there is not nearly as much
unanimity.
I actually look forward to a day when DHCPv6 is more common, and then
I'd like to revisit this topic.
> Historically (8.0-RELEASE and prior), there was a global rc.conf knob
> for ipv6 (ipv6_enable, default="NO") that performed several functions:
>
> a) Enabled (or disabled) ipv6 link-local address for every interface
> (auto_linklocal AND -ifdisabled)
> b) Enabled (or disabled) ipv6 SLAAC by default for every interface by
> setting the global net.inet6.ip6.accept_rtadv=1 sysctl
> c) inherently specified utilization of a ipv6 address (AAAA) over an
> ipv4 address (A) when both were available from a dns query when using
> getaddrinfo()
> d) Others I can not think of at the moment ?
>
> As well, there has always been a per-interface variable for IPv4 dhcp
> (The pseudo-variable of "dhcp" on an ifconfig_IF rc.conf line), but no
> global knob.
>
> Now, I propose two new global variables: ipv6_slaac_default_enable,
> ipv4_dhcp_default_enable
> and several new/updated per-interface pseudo variables: auto, noauto,
> accept_rtadv, -accept_rtadv, slaac, noslaac, dhcp, nodhcp
I think (others may disagree) that this is too much complexity. I do
however agree with the idea of decoupling some of the functions that
ipv6_enable did previously. My patch doesn't change the current semantic
of ipv6_prefer, and adds the ability to do specify SLAAC, direct
configuration, and a NORTADV knob on a per-ipv6-interface basis.
> Changelist:
> 4) Misc changes/fixes:
> Changed ifconfig_up() to use ipv6_autoconfif() rather than
> re-checking some values for itself,
I did my own pass on ifconfig_up(), but it ended up looking similar to
yours in some ways. In particular, I agree with this change and have
adopted it.
> and now allow
> ifconfig_em0_ipv6="inet6 2001:db8::1" to work with AND without
> user-specified "inet6", as it used to be implied, and most recently
> was required, and is now optional.
ifconfig_IF for v4 has always required "inet <address>" I don't see any
reason to NOT require inet6 for ifconfig_IF_ipv6. Making things easier
for users is a good thing, but sometimes too many options make things
worse, not better. :)
> Change ipv6_network_interfaces to default to "AUTO" just like
> network_interfaces (consistency is the theme)
This I agree with (on both counts), as I've stated previously.
More to come on -current.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
------------------------------
Message: 7
Date: Sat, 3 Apr 2010 12:15:53 +0200
From: Stefan Bethke <s...@lassitu.de>
Subject: Re: bridged wlan/ether still the same
To: Randy Bush <ra...@psg.com>
Cc: FreeBSD Net <freeb...@FreeBSD.org>, FreeBSD Current
<freebsd...@freebsd.org>
Message-ID: <3175D5A3-B013-4E86...@lassitu.de>
Content-Type: text/plain; charset=us-ascii
Am 02.04.2010 um 09:45 schrieb Randy Bush:
> it's the bridge that worries me. took me a while to make it work
It looks sane to me. Here's my slightly more convoluted setup (8-stable):
cloned_interfaces="bridge0 tap0 vlan1 vlan2 vlan3 gif0"
ifconfig_bridge0="ether 02:00:00:00:00:01 addm tap0 addm vlan1"
ifconfig_bridge0_alias0="inet 44.128.65.1/26"
ifconfig_em0="up"
ifconfig_vlan1="vlandev em0 vlan 1"
ifconfig_vlan2="44.128.65.249/29 vlandev em0 vlan 2"
ifconfig_vlan3="172.23.54.1/24 vlandev em0 vlan 3"
ifconfig_tap0="up"
I've set bridge0's MAC address to avoid sillyness with a cheap desktop switch that would get confused on reboots.
HTH,
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
------------------------------
End of freebsd-net Digest, Vol 365, Issue 6
*******************************************