Folks, does the following patch make sense:
server@[/u/vijay/bsd/CODE/cur/sys/sys]# svn diff mbuf.h
Index: mbuf.h
===
--- mbuf.h (revision 240548)
+++ mbuf.h (working copy)
@@ -832,6 +832,8 @@
((m)->m_flags & M_EXT ?
Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in
/boot/loader.conf
State-Changed-From-To: feedback->open
State-Changed-By: emaste
State-Changed-When: Wed Sep 26 00:37:49 UTC 2012
State-Changed-Why:
Ahh, it's OpenVPN that consumed 100% CPU, so non-OpenVPN TAP consumers are
l
Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in
/boot/loader.conf
State-Changed-From-To: open->feedback
State-Changed-By: emaste
State-Changed-When: Wed Sep 26 00:33:10 UTC 2012
State-Changed-Why:
Does this problem persist on current releases?
I have if_tap loaded via loa
On my systems, where I rebuild "world" by hand, I usually disable INET6
(WITHOUT_INET6 is documented in src.conf(5)) -- because it is still a waste on
today's Internet with most ISPs.
Unfortunately, this effectively disables tools like nmap, which use an
expression like:
Packet capture fi
On Tue, Sep 25, 2012 at 1:40 PM, Jack Vogel wrote:
> Ah yes, at one time I was keeping the RX side lock when calling the stack,
> but then as I recall that had problems, so the code now releases and
> reaquires
> as you can see. It results in some contention but I'm not sure that's
> avoidable.
J
Ah yes, at one time I was keeping the RX side lock when calling the stack,
but then as I recall that had problems, so the code now releases and
reaquires
as you can see. It results in some contention but I'm not sure that's
avoidable.
I've seen some LRO related panics on the 1G driver that may be
On 9/25/12 1:07 PM, Ryan Stone wrote:
When ng_snd_item tries to send an item, has to acquire a "lock" on the
node that it's sending to (I put lock in quotes because this isn't a
standard FreeBSD synchronization primitive like a rw_lock or anything;
netgraph has rolled its own synchronization prim
> Vijay, can you test this to see if it helps with your test case?
>
>> Jack
John, apologies for the delay. I have some data to share now.
With your patch, the transmit side lock contention is all gone.
However I still see receive side contention. I have MSI/X enabled,
with one hw queue per-port.
On 9/25/2012 11:08 AM, Rudy (bulk) wrote:
On 9/24/12 11:52 PM, Hooman Fazaeli wrote:
sysctl dev.em.1
From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012)
# sysctl dev.em.1
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2
dev.em.1.%driver: em
dev.em.1.%lo
On 9/25/2012 11:08 AM, Rudy (bulk) wrote:
On 9/24/12 11:52 PM, Hooman Fazaeli wrote:
sysctl dev.em.1
From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012)
# sysctl dev.em.1
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2
dev.em.1.%driver: em
dev.em.1.%lo
I view the TCP stack code of FreeBSD-CURRENT recently. It seems that
current TCP/IP stack does not support D-SACK. Does someone will add D-SACK
support in the future. Windows 7 and linux have add D-SACK supported.
The detail of D-SACK is described in RFC2883.
_
On Sep 25, 2012, at 12:38 AM, "Rudy (bulk)" wrote:
> On 9/24/12 11:52 PM, Hooman Fazaeli wrote:
>> sysctl dev.em.1
>
> From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13
> 2012)
>
> # sysctl dev.em.1
> dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2
> dev.em.
On 9/24/12 11:52 PM, Hooman Fazaeli wrote:
sysctl dev.em.1
From the side having the 'No buffer space available' (FreeBSD 8.3 Sep
13 2012)
# sysctl dev.em.1
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0
dev.em.1.%pnpinfo
13 matches
Mail list logo
