Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-net Digest, Vol 363, Issue 6

0 views

Skip to first unread message

freebsd-n...@freebsd.org

unread,

Mar 20, 2010, 8:00:15 AM3/20/10

to freeb...@freebsd.org

Send freebsd-net mailing list submissions to
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. [patch] ng_netflow (??????? ???????)
2. Please pay attention to fix bug kern/141285 (Prokofyev S.P.)
3. Re: Please pay attention to fix bug kern/141285 (Xin LI)
4. Re: Please pay attention to fix bug kern/141285 (Prokofyev S.P.)
5. Re: Please pay attention to fix bug kern/141285 (Pyun YongHyeon)
6. Re: Please pay attention to fix bug kern/141285 (Pyun YongHyeon)
7. Samba read speed performance tuning (Dan Naumov)
8. Re: kern/144874: [if_bridge] [patch] if_bridge frees mbuf
after pfil hooks returns non-zero (lin...@FreeBSD.org)
9. Re: kern/139117: [lagg] wlan boot timing (EBUSY) (David Horn)
10. Re: Samba read speed performance tuning (Dan Naumov)
11. Re: kern/144874: [if_bridge] [patch] if_bridge frees mbuf
after pfil hooks returns non-zero (Gleb Kurtsou)
12. Re: Samba read speed performance tuning (Gary Gatten)
13. Re: Samba read speed performance tuning (Adam Vande More)
14. Re: kern/124225: [ndis] [patch] ndis network driver sometimes
loses network connection (lin...@FreeBSD.org)
15. Re: kern/144882: MacBookPro =>4.1 does not connect to BSD in
hostap with adapters based on ralink and used if_rum and if_ural
drivers (bru...@FreeBSD.org)
16. why zero-copy sockets(9) are not popular? (Alexander Bubnov)
17. Re: Bug in tcp_output? (Rui Paulo)

----------------------------------------------------------------------

Message: 1
Date: Fri, 19 Mar 2010 15:39:34 +0300
From: ??????? ??????? <dim...@gmail.com>
Subject: [patch] ng_netflow
To: freeb...@freebsd.org
Message-ID:
<50a120641003190539n7d6...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello.
I saw patches for ng_netflow to make netflow v9 there
http://lists.freebsd.org/pipermail/freebsd-net/2009-September/022911.html
What's state of this patches? Is this code included in freebsd? Or will be
include in future release?

------------------------------

Message: 2
Date: Fri, 19 Mar 2010 16:40:44 +0200
From: "Prokofyev S.P." <pr...@skylinetele.com>
Subject: Please pay attention to fix bug kern/141285
To: freeb...@freebsd.org
Message-ID: <4BA38CEC...@skylinetele.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi ALL !

Please pay attention to fix bug kern/141285(kern/141843) !

Thank you very much!

------------------------------

Message: 3
Date: Fri, 19 Mar 2010 09:47:45 -0700
From: Xin LI <del...@delphij.net>
Subject: Re: Please pay attention to fix bug kern/141285
To: freeb...@freebsd.org
Cc: Jack Vogel <jfv...@gmail.com>, Pyun YongHyeon
<yon...@FreeBSD.ORG>
Message-ID: <4BA3AAB1...@delphij.net>
Content-Type: text/plain; charset=UTF-8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010/03/19 07:40, Prokofyev S.P. wrote:
> Hi ALL !
>
> Please pay attention to fix bug kern/141285(kern/141843) !

Looking at the PR, it seems that Pyun have a patch against em(4) and
there is some confirmation that it has fixed the issue. Did it solved
your problem?

Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBAgAGBQJLo6qxAAoJEATO+BI/yjfBX4cIAMvBqAMLSuSDIZYy4F2thDdq
Niv4Phq7Ob9xrmpC6368fknZu/w+/4Z9I6Bpwx/On67JCHuIcmCezaOVuulLFn0Z
We3Hq0CbGw4hS/rASjEMGHAVfiM1+gc88ohSxLMY2iCzDJ5kXId3O/+gpnZUGi3A
aGgOq7jrZtYgW7gyL6KLVzw8I0pK68QZN+4CBmeD7jczNAPNXH35qARgeJEbpXWY
q8Z81/ibtVaU+jfMjQvkULCE3+9+muklM2lcjHnobYLWzFqsP27sYazCW4TmDV6n
IqXJdt5KrZqUsAg6EeTrOCNtjTO6b+b6Jb3zE+CNThvozhWsWah5IQcmhdFt8qE=
=JlNN
-----END PGP SIGNATURE-----

------------------------------

Message: 4
Date: Fri, 19 Mar 2010 19:02:28 +0200
From: "Prokofyev S.P." <pr...@skylinetele.com>
Subject: Re: Please pay attention to fix bug kern/141285
To: d...@delphij.net
Cc: freeb...@freebsd.org, Xin LI <del...@delphij.net>, Jack Vogel
<jfv...@gmail.com>, Pyun YongHyeon <yon...@FreeBSD.ORG>
Message-ID: <4BA3AE24...@skylinetele.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 19.03.2010 18:47, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2010/03/19 07:40, Prokofyev S.P. wrote:
>
>> Hi ALL !
>>
>> Please pay attention to fix bug kern/141285(kern/141843) !
>>
> Looking at the PR, it seems that Pyun have a patch against em(4) and
> there is some confirmation that it has fixed the issue. Did it solved
> your problem?
>
> Cheers,
> - --
> Xin LI<del...@delphij.net> http://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (FreeBSD)
>
> iQEcBAEBAgAGBQJLo6qxAAoJEATO+BI/yjfBX4cIAMvBqAMLSuSDIZYy4F2thDdq
> Niv4Phq7Ob9xrmpC6368fknZu/w+/4Z9I6Bpwx/On67JCHuIcmCezaOVuulLFn0Z
> We3Hq0CbGw4hS/rASjEMGHAVfiM1+gc88ohSxLMY2iCzDJ5kXId3O/+gpnZUGi3A
> aGgOq7jrZtYgW7gyL6KLVzw8I0pK68QZN+4CBmeD7jczNAPNXH35qARgeJEbpXWY
> q8Z81/ibtVaU+jfMjQvkULCE3+9+muklM2lcjHnobYLWzFqsP27sYazCW4TmDV6n
> IqXJdt5KrZqUsAg6EeTrOCNtjTO6b+b6Jb3zE+CNThvozhWsWah5IQcmhdFt8qE=
> =JlNN
> -----END PGP SIGNATURE-----
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>

I tested that patch, but it has been fixed kern/141843
http://lists.freebsd.org/pipermail/freebsd-net/2010-January/024173.html

------------------------------

Message: 5
Date: Fri, 19 Mar 2010 10:44:50 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: Please pay attention to fix bug kern/141285
To: "Prokofyev S.P." <pr...@skylinetele.com>
Cc: j...@FreeBSD.org, freeb...@freebsd.org
Message-ID: <2010031917...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"

On Fri, Mar 19, 2010 at 04:40:44PM +0200, Prokofyev S.P. wrote:
> Hi ALL !
>
> Please pay attention to fix bug kern/141285(kern/141843) !
>

igb(4) also has a similar issue but it seems igb(4) does not even
advertise IFCAP_VLAN_HWFILTER capability. igb(4) may have to remove
VLAN event handler or should implement IFCAP_VLAN_HWFILTER to
support VLAN hardware filtering.

I have a patch for the hardware VLAN filtering of em(4). But it
wouldn't address the issue reported in the PR. The root cause of
issue was em(4) wants to reset controller whenever new VLAN is
registered/unregistered. I'm not sure this is requirement of
hardware. If this is requirement of hardware there is no way to
avoid the controller reset unless you disable vlanhwfilter feature.

#ifconfig em0 -vlanhwfilter

em(4) in HEAD disabled VLAN hardware filtering by default so if you
use that version you wouldn't encounter the issue again. Attached
patch is small diff for VLAN hardware filtering which tries to
avoid unnecessary controller reset and added missing lock. If
hardware allows dynamic changing of VLAN filtering table we could
completely bypass the controller reset. Jack may know the details.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: em.vlan_hwfilter.patch
Type: text/x-diff
Size: 1089 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20100319/69141e51/em.vlan_hwfilter-0001.bin

------------------------------

Message: 6
Date: Fri, 19 Mar 2010 10:47:09 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: Please pay attention to fix bug kern/141285
To: "Prokofyev S.P." <pr...@skylinetele.com>
Cc: j...@FreeBSD.org, freeb...@freebsd.org
Message-ID: <2010031917...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"

On Fri, Mar 19, 2010 at 10:44:50AM -0700, Pyun YongHyeon wrote:
> On Fri, Mar 19, 2010 at 04:40:44PM +0200, Prokofyev S.P. wrote:
> > Hi ALL !
> >
> > Please pay attention to fix bug kern/141285(kern/141843) !
> >
>
> igb(4) also has a similar issue but it seems igb(4) does not even
> advertise IFCAP_VLAN_HWFILTER capability. igb(4) may have to remove
> VLAN event handler or should implement IFCAP_VLAN_HWFILTER to
> support VLAN hardware filtering.
>
> I have a patch for the hardware VLAN filtering of em(4). But it
> wouldn't address the issue reported in the PR. The root cause of
> issue was em(4) wants to reset controller whenever new VLAN is
> registered/unregistered. I'm not sure this is requirement of
> hardware. If this is requirement of hardware there is no way to
> avoid the controller reset unless you disable vlanhwfilter feature.
>
> #ifconfig em0 -vlanhwfilter
>
> em(4) in HEAD disabled VLAN hardware filtering by default so if you
> use that version you wouldn't encounter the issue again. Attached
> patch is small diff for VLAN hardware filtering which tries to
> avoid unnecessary controller reset and added missing lock. If
> hardware allows dynamic changing of VLAN filtering table we could
> completely bypass the controller reset. Jack may know the details.

Oops, posted old patch. Here is new one.
-------------- next part --------------
Index: sys/dev/e1000/if_em.c
===================================================================
--- sys/dev/e1000/if_em.c (revision 205300)
+++ sys/dev/e1000/if_em.c (working copy)
@@ -4652,10 +4652,15 @@

index = (vtag >> 5) & 0x7F;
bit = vtag & 0x1F;
+ EM_CORE_LOCK(adapter);
em_shadow_vfta[index] |= (1 << bit);
++adapter->num_vlans;
/* Re-init to load the changes */
- em_init(adapter);
+ if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
+ (ifp->if_capabilities & IFCAP_VLAN_HWFILTER) != 0 &&
+ (ifp->if_capenable & IFCAP_VLAN_HWFILTER) != 0)
+ em_init_locked(adapter);
+ EM_CORE_UNLOCK(adapter);
}

/*
@@ -4676,10 +4681,15 @@

index = (vtag >> 5) & 0x7F;
bit = vtag & 0x1F;
+ EM_CORE_LOCK(adapter);
em_shadow_vfta[index] &= ~(1 << bit);
--adapter->num_vlans;
/* Re-init to load the changes */
- em_init(adapter);
+ if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
+ (ifp->if_capabilities & IFCAP_VLAN_HWFILTER) != 0 &&
+ (ifp->if_capenable & IFCAP_VLAN_HWFILTER) != 0)
+ em_init_locked(adapter);
+ EM_CORE_UNLOCK(adapter);
}

static void

------------------------------

Message: 7
Date: Fri, 19 Mar 2010 23:14:47 +0200
From: Dan Naumov <dan.n...@gmail.com>
Subject: Samba read speed performance tuning
To: freeb...@freebsd.org, freebsd-...@freebsd.org,
FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>,
freebsd-p...@freebsd.org
Message-ID:
<cf9b1ee01003191414q35d...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board
using an Intel gigabit nic with the em driver, running on top of a ZFS
mirror, I was seeing a strange issue. Local reads and writes to the
pool easily saturate the disks with roughly 75mb/s throughput, which
is roughly the best these drives can do. However, working with Samba,
writes to a share could easily pull off 75mb/s and saturate the disks,
but reads off a share were resulting in rather pathetic 18mb/s
throughput.

I found a threadon the FreeBSD forums
(http://forums.freebsd.org/showthread.php?t=9187) and followed the
suggested advice. I rebuilt Samba with AIO support, kldloaded the aio
module and made the following changes to my smb.conf

From:
socket options=TCP_NODELAY

To:
socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
min receivefile size=16384
use sendfile=true
aio read size = 16384
aio write size = 16384
aio write behind = true
dns proxy = no[/CODE]

This showed a very welcome improvement in read speed, I went from
18mb/s to 48mb/s. The write speed remained unchanged and was still
saturating the disks. Now I tried the suggested sysctl tunables:

atombsd# sysctl net.inet.tcp.delayed_ack=0
net.inet.tcp.delayed_ack: 1 -> 0

atombsd# sysctl net.inet.tcp.path_mtu_discovery=0
net.inet.tcp.path_mtu_discovery: 1 -> 0

atombsd# sysctl net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.recvbuf_inc: 16384 -> 524288

atombsd# sysctl net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.recvbuf_max: 262144 -> 16777216

atombsd# sysctl net.inet.tcp.sendbuf_inc=524288
net.inet.tcp.sendbuf_inc: 8192 -> 524288

atombsd# sysctl net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.sendbuf_max: 262144 -> 16777216

atombsd# sysctl net.inet.tcp.sendspace=65536
net.inet.tcp.sendspace: 32768 -> 65536

atombsd# sysctl net.inet.udp.maxdgram=57344
net.inet.udp.maxdgram: 9216 -> 57344

atombsd# sysctl net.inet.udp.recvspace=65536
net.inet.udp.recvspace: 42080 -> 65536

atombsd# sysctl net.local.stream.recvspace=65536
net.local.stream.recvspace: 8192 -> 65536

atombsd# sysctl net.local.stream.sendspace=65536
net.local.stream.sendspace: 8192 -> 65536

This improved the read speeds a further tiny bit, now I went from
48mb/s to 54mb/s. This is it however, I can't figure out how to
increase Samba read speed any further. Any ideas?

------------------------------

Message: 8
Date: Fri, 19 Mar 2010 23:53:39 GMT
From: lin...@FreeBSD.org
Subject: Re: kern/144874: [if_bridge] [patch] if_bridge frees mbuf
after pfil hooks returns non-zero
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201003192353....@freefall.freebsd.org>

Old Synopsis: [patch] if_bridge frees mbuf after pfil hooks returns non-zero
New Synopsis: [if_bridge] [patch] if_bridge frees mbuf after pfil hooks returns non-zero

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Mar 19 23:53:11 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=144874

------------------------------

Message: 9
Date: Sat, 20 Mar 2010 01:00:15 GMT
From: David Horn <dhor...@gmail.com>
Subject: Re: kern/139117: [lagg] wlan boot timing (EBUSY)
To: freeb...@FreeBSD.org
Message-ID: <201003200100....@freefall.freebsd.org>

The following reply was made to PR kern/139117; it has been noted by GNATS.

From: David Horn <dhor...@gmail.com>
To: bug-fo...@FreeBSD.org, dhor...@gmail.com
Cc:
Subject: Re: kern/139117: [lagg] wlan boot timing (EBUSY)
Date: Fri, 19 Mar 2010 20:59:19 -0400

--001485f7d62453ff1d048230f91d
Content-Type: text/plain; charset=ISO-8859-1

Fixed by r204901 - delphij removal of OACTIVE check (also attached as
a text diff)

After testing this several different ways, this seems to work 100% for me.
Please close as fixed after MFC.

--Thanks!

--Dave Horn

--001485f7d62453ff1d048230f91d
Content-Type: text/plain; charset=US-ASCII; name="lagg_oactive.diff.txt"
Content-Disposition: attachment; filename="lagg_oactive.diff.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g6zpiz4i0

SW5kZXg6IGlmX2xhZ2cuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBpZl9sYWdnLmMJKHJldmlzaW9uIDIwNDg3
NykKKysrIGlmX2xhZ2cuYwkod29ya2luZyBjb3B5KQpAQCAtNDg0LDEwICs0ODQsNiBAQAogCWlm
IChzYy0+c2NfY291bnQgPj0gTEFHR19NQVhfUE9SVFMpCiAJCXJldHVybiAoRU5PU1BDKTsKIAot
CS8qIE5ldyBsYWdnIHBvcnQgaGFzIHRvIGJlIGluIGFuIGlkbGUgc3RhdGUgKi8KLQlpZiAoaWZw
LT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX09BQ1RJVkUpCi0JCXJldHVybiAoRUJVU1kpOwotCiAJ
LyogQ2hlY2sgaWYgcG9ydCBoYXMgYWxyZWFkeSBiZWVuIGFzc29jaWF0ZWQgdG8gYSBsYWdnICov
CiAJaWYgKGlmcC0+aWZfbGFnZyAhPSBOVUxMKQogCQlyZXR1cm4gKEVCVVNZKTsK
--001485f7d62453ff1d048230f91d--

------------------------------

Message: 10
Date: Sat, 20 Mar 2010 03:28:02 +0200
From: Dan Naumov <dan.n...@gmail.com>
Subject: Re: Samba read speed performance tuning
To: freeb...@freebsd.org, freebsd-...@freebsd.org,
FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>,
freebsd-p...@freebsd.org
Message-ID:
<cf9b1ee01003191828g5be...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 19, 2010 at 11:14 PM, Dan Naumov <dan.n...@gmail.com> wrote:
> On a FreeBSD 8.0-RELEASE/amd64 system with a Supermicro X7SPA-H board
> using an Intel gigabit nic with the em driver, running on top of a ZFS
> mirror, I was seeing a strange issue. Local reads and writes to the
> pool easily saturate the disks with roughly 75mb/s throughput, which
> is roughly the best these drives can do. However, working with Samba,
> writes to a share could easily pull off 75mb/s and saturate the disks,
> but reads off a share were resulting in rather pathetic 18mb/s
> throughput.
>
> I found a threadon the FreeBSD forums
> (http://forums.freebsd.org/showthread.php?t=9187) and followed the
> suggested advice. I rebuilt Samba with AIO support, kldloaded the aio
> module and made the following changes to my smb.conf
>
> From:
> socket options=TCP_NODELAY
>
> To:
> socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY
> min receivefile size=16384
> use sendfile=true
> aio read size = 16384
> aio write size = 16384
> aio write behind = true
> dns proxy = no[/CODE]
>
> This showed a very welcome improvement in read speed, I went from
> 18mb/s to 48mb/s. The write speed remained unchanged and was still
> saturating the disks. Now I tried the suggested sysctl tunables:
>
> atombsd# sysctl net.inet.tcp.delayed_ack=0
> net.inet.tcp.delayed_ack: 1 -> 0
>
> atombsd# sysctl net.inet.tcp.path_mtu_discovery=0
> net.inet.tcp.path_mtu_discovery: 1 -> 0
>
> atombsd# sysctl net.inet.tcp.recvbuf_inc=524288
> net.inet.tcp.recvbuf_inc: 16384 -> 524288
>
> atombsd# sysctl net.inet.tcp.recvbuf_max=16777216
> net.inet.tcp.recvbuf_max: 262144 -> 16777216
>
> atombsd# sysctl net.inet.tcp.sendbuf_inc=524288
> net.inet.tcp.sendbuf_inc: 8192 -> 524288
>
> atombsd# sysctl net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.sendbuf_max: 262144 -> 16777216
>
> atombsd# sysctl net.inet.tcp.sendspace=65536
> net.inet.tcp.sendspace: 32768 -> 65536
>
> atombsd# sysctl net.inet.udp.maxdgram=57344
> net.inet.udp.maxdgram: 9216 -> 57344
>
> atombsd# sysctl net.inet.udp.recvspace=65536
> net.inet.udp.recvspace: 42080 -> 65536
>
> atombsd# sysctl net.local.stream.recvspace=65536
> net.local.stream.recvspace: 8192 -> 65536
>
> atombsd# sysctl net.local.stream.sendspace=65536
> net.local.stream.sendspace: 8192 -> 65536
>
> This improved the read speeds a further tiny bit, now I went from
> 48mb/s to 54mb/s. This is it however, I can't figure out how to
> increase Samba read speed any further. Any ideas?

Oh my god... Why did noone tell me how much of an enormous performance
boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is.
My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie.
they are now nearly 25% faster than reading off an individual disk)
and reads off a Samba share skyrocketed from 50mb/s to 90mb/s.

By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386
systems and on any amd64 systems with less than 4GB of avaiable
memory. My system is amd64 with 4gb ram, but integrated video eats
some of that, so the autotuning disabled the prefetch. I had read up
on it and a fair amount of people seemed to have performance issues
caused by having prefetch enabled and get better results with it
turned off, in my case however, it seems that enabling it gave a
really solid boost to performance.

- Sincerely
Dan Naumov

------------------------------

Message: 11
Date: Sat, 20 Mar 2010 01:50:03 GMT
From: Gleb Kurtsou <gleb.k...@gmail.com>
Subject: Re: kern/144874: [if_bridge] [patch] if_bridge frees mbuf
after pfil hooks returns non-zero
To: freeb...@FreeBSD.org
Message-ID: <201003200150....@freefall.freebsd.org>

The following reply was made to PR kern/144874; it has been noted by GNATS.

From: Gleb Kurtsou <gleb.k...@gmail.com>
To: bug-fo...@FreeBSD.org, jacob...@comcast.net
Cc:
Subject: Re: kern/144874: [if_bridge] [patch] if_bridge frees mbuf after
pfil hooks returns non-zero
Date: Sat, 20 Mar 2010 03:50:04 +0200

[...]
> Create a simple pfil hook and install it with pfil_add_hook(PFIL_IN).
> The hook should drop (some) packets by returning a non-zero value. The
> hook should free the mbuf on dropped packets by calling m_freem(*mp).
> The filter should _not_ modify the mbuf pointer (mp). Install a
^^^^^^^^^ documentation is wrong here.
As far as I can see all firewalls in the tree zero mp after free,
something like:
if (chk && *m) {
m_freem(*m);
*m = NULL;
}

Correct fix would be to update documentation and add KASSERT to
pfil_run_hooks checking *mp == 0 if hook returned non-zero result.

> if_bridge on the system, and pass traffic through the bridge, such
> that at least one packet gets dropped by the pfil hook. At some point
> shortly after that the system will panic. The panic is usually occurs
> in sbflush_internal(), though there are other ways that the corruption
> can manifest.

------------------------------

Message: 12
Date: Fri, 19 Mar 2010 20:49:34 -0500
From: Gary Gatten <Gga...@waddell.com>
Subject: Re: Samba read speed performance tuning
To: "'dan.n...@gmail.com'" <dan.n...@gmail.com>,
"'freeb...@freebsd.org'" <freeb...@freebsd.org>,
"'freebsd-...@freebsd.org'" <freebsd-...@freebsd.org>,
"'freebsd...@freebsd.org'" <freebsd...@freebsd.org>,
"'freebsd-p...@freebsd.org'" <freebsd-p...@freebsd.org>
Message-ID:
<30209_1269049775_4BA429AF_30209_895_1_D...@WADPMBXV0.waddell.com>

Content-Type: text/plain; charset="utf-8"

It MAY make a big diff, but make sure during your tests you use unique files or flush the cache or you'll me testing cache speed and not disk speed.

----- Original Message -----
From: owner-freeb...@freebsd.org <owner-freeb...@freebsd.org>
To: freeb...@freebsd.org <freeb...@freebsd.org>; freebsd-...@freebsd.org <freebsd-...@freebsd.org>; FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>; freebsd-p...@freebsd.org <freebsd-p...@freebsd.org>
Sent: Fri Mar 19 20:28:02 2010
Subject: Re: Samba read speed performance tuning

- Sincerely
Dan Naumov

<font size="1">
<div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'>
</div>
"This email is intended to be reviewed by only the intended recipient
and may contain information that is privileged and/or confidential.
If you are not the intended recipient, you are hereby notified that
any review, use, dissemination, disclosure or copying of this email
and its attachments, if any, is strictly prohibited. If you have
received this email in error, please immediately notify the sender by
return email and delete this email from your system."
</font>

------------------------------

Message: 13
Date: Fri, 19 Mar 2010 21:32:50 -0500
From: Adam Vande More <amvan...@gmail.com>
Subject: Re: Samba read speed performance tuning
To: Dan Naumov <dan.n...@gmail.com>
Cc: freeb...@freebsd.org, freebsd-p...@freebsd.org,
FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>,
freebsd-...@freebsd.org
Message-ID:
<6201873e1003191932g447...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 19, 2010 at 8:28 PM, Dan Naumov <dan.n...@gmail.com> wrote:

> Oh my god... Why did noone tell me how much of an enormous performance
> boost vfs.zfs.prefetch_disable=0 (aka actually enabling prefetch) is.
> My local reads off the mirror pool jumped from 75mb/s to 96mb/s (ie.
> they are now nearly 25% faster than reading off an individual disk)
> and reads off a Samba share skyrocketed from 50mb/s to 90mb/s.
>
> By default, FreeBSD sets vfs.zfs.prefetch_disable to 1 on any i386
> systems and on any amd64 systems with less than 4GB of avaiable
> memory. My system is amd64 with 4gb ram, but integrated video eats
> some of that, so the autotuning disabled the prefetch. I had read up
> on it and a fair amount of people seemed to have performance issues
> caused by having prefetch enabled and get better results with it
> turned off, in my case however, it seems that enabling it gave a
> really solid boost to performance.
>

My home VBox server is similar specs and I enabled the prefetch from the
start. A few days ago, I added an intel SSD as the zpool cache device and
the read speed is mind blowing now. This is from inside a VM frunning on it
meaning ad0 is really a vdi. Once the cache is populated, HD latency is
mostly a thing of the past.

# diskinfo -tv /dev/ad0
/dev/ad0
512 # sectorsize
12884901888 # mediasize in bytes (12G)
25165824 # mediasize in sectors
24966 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
VBf9752473-05343e4e # Disk ident.

Seek times:
Full stroke: 250 iter in 0.082321 sec = 0.329 msec
Half stroke: 250 iter in 0.078944 sec = 0.316 msec
Quarter stroke: 500 iter in 0.161266 sec = 0.323 msec
Short forward: 400 iter in 0.128624 sec = 0.322 msec
Short backward: 400 iter in 0.131770 sec = 0.329 msec
Seq outer: 2048 iter in 0.667510 sec = 0.326 msec
Seq inner: 2048 iter in 0.691691 sec = 0.338 msec
Transfer rates:
outside: 102400 kbytes in 0.722864 sec = 141659 kbytes/sec
middle: 102400 kbytes in 0.813619 sec = 125857 kbytes/sec
inside: 102400 kbytes in 0.838129 sec = 122177 kbytes/sec

--
Adam Vande More

------------------------------

Message: 14
Date: Sat, 20 Mar 2010 02:38:25 GMT
From: lin...@FreeBSD.org
Subject: Re: kern/124225: [ndis] [patch] ndis network driver sometimes
loses network connection
To: lin...@FreeBSD.org, cok...@FreeBSD.org, freeb...@FreeBSD.org
Message-ID: <201003200238....@freefall.freebsd.org>

Synopsis: [ndis] [patch] ndis network driver sometimes loses network connection

Responsible-Changed-From-To: cokane->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Mar 20 02:37:53 UTC 2010
Responsible-Changed-Why:
returned to the pool by request (some time ago.)

http://www.freebsd.org/cgi/query-pr.cgi?pr=124225

------------------------------

Message: 15
Date: Sat, 20 Mar 2010 05:17:00 GMT
From: bru...@FreeBSD.org
Subject: Re: kern/144882: MacBookPro =>4.1 does not connect to BSD in
hostap with adapters based on ralink and used if_rum and if_ural
drivers
To: bru...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201003200517....@freefall.freebsd.org>

Synopsis: MacBookPro =>4.1 does not connect to BSD in hostap with adapters based on ralink and used if_rum and if_ural drivers

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Sat Mar 20 05:16:16 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=144882

------------------------------

Message: 16
Date: Sat, 20 Mar 2010 13:06:54 +0300
From: Alexander Bubnov <alexande...@gmail.com>
Subject: why zero-copy sockets(9) are not popular?
To: freeb...@freebsd.org
Message-ID:
<c3e287ff1003200306l162...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello, all!
Anybody knows why zero copy is not popular although this technique allows
to increase performance of servers? It is very hard to find any examples of
zero-copy for FreeBSD.

Thank you in advance.

--
/BR, Alexander

------------------------------

Message: 17
Date: Sat, 20 Mar 2010 11:14:07 +0000
From: Rui Paulo <rpa...@freebsd.org>
Subject: Re: Bug in tcp_output?
To: Chris Harrer <cjha...@comcast.net>
Cc: freeb...@freebsd.org
Message-ID: <2FEF7D36-31B7-4FD7...@freebsd.org>
Content-Type: text/plain; charset=windows-1252

On 18 Mar 2010, at 20:19, Chris Harrer wrote:

> Hi All,
>
>
>
> In the following block of code, running on a x86_64 platform, I believe that
> cwin should be declared as an int:
>
> /*
>
> * If snd_nxt == snd_max and we have transmitted a FIN, the
>
> * offset will be > 0 even if so_snd.sb_cc is 0, resulting in
>
> * a negative length. This can also occur when TCP opens up
>
> * its congestion window while receiving additional duplicate
>
> * acks after fast-retransmit because TCP will reset snd_nxt
>
> * to snd_max after the fast-retransmit.
>
> *
>
> * In the normal retransmit-FIN-only case, however, snd_nxt will
>
> * be set to snd_una, the offset will be 0, and the length may
>
> * wind up 0.
>
> *
>
> * If sack_rxmit is true we are retransmitting from the scoreboard
>
> * in which case len is already set.
>
> */
>
> if (sack_rxmit == 0) {
>
> if (sack_bytes_rxmt == 0)
>
> len = ((long)ulmin(so->so_snd.sb_cc, sendwin) - off);
>
> else {
>
> long cwin; �-- Should be an int
>
>
>
> /*
>
> * We are inside of a SACK recovery episode and are
>
> * sending new data, having retransmitted all the
>
> * data possible in the scoreboard.
>
> */
>
> len = ((long)ulmin(so->so_snd.sb_cc, tp->snd_wnd)
>
> - off);
>
> /*
>
> * Don't remove this (len > 0) check !
>
> * We explicitly check for len > 0 here (although it
>
> * isn't really necessary), to work around a gcc
>
> * optimization issue - to force gcc to compute
>
> * len above. Without this check, the computation
>
> * of len is bungled by the optimizer.
>
> */
>
> if (len > 0) {
>
> cwin = tp->snd_cwnd -
>
> (tp->snd_nxt - tp->sack_newdata) -
>
> sack_bytes_rxmt;
>
> if (cwin < 0)
>
> cwin = 0;
>
> len = lmin(len, cwin);
>
> }
>
> }
>
> }
>
>
>
> Consider the case where:
>
> sack_rxmit = 0
>
> sack_bytes_rxmt = 0x2238
>
> off = 0
>
> len =0xa19c
>
> tp->snd_cwnd = 0x2238
>
> tp->snd_nxt = 0xdd6d7974
>
> tp->sack_newdata = 0xdd6d6858
>
> In this case cwin evaluates to 0x00000000ffffe37c, which is not <0, but
> instead huge. This causes the remaining data on the socket�s so->so_snd
> buffer to be sent to the network causing more problems at the receiver which
> is already dropping frames.

I see. This is most likely a bug. Can you send-pr so this doesn't get lost?

Regards,
--
Rui Paulo

------------------------------

End of freebsd-net Digest, Vol 363, Issue 6
*******************************************

0 new messages