Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
The following reply was made to PR kern/179429; it has been noted by GNATS.
From: Tiago Daniel Jacobs
To: bug-follo...@freebsd.org, o...@tdj.cc
Cc:
Subject: Re: kern/179429: [tap] STP enabled tap bridge
Date: Mon, 22 Jul 2013 13:07:56 -0300
It's a bug because STP don't work as expected when u
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: Meny Yossefi
To: John Baldwin , "bug-follo...@freebsd.org"
Cc:
Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for
fragmented packets
Date: Mon, 22 Jul 2013 14:11:51 +
--_000_F2E47A3
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: John Baldwin
To: Meny Yossefi
Cc: "bug-follo...@freebsd.org"
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented
packets
Date: Mon, 22 Jul 2013 11:40:08 -0400
On Monday, July 22, 2013
trafdev wrote this message on Mon, Jul 15, 2013 at 13:04 -0700:
> Yep I think it's wasting of resources, poll manager should somehow be
> configured to update only one process/thread.
> Anyone know how to do that?
This isn't currently possible w/o a shared kqueue, since the event is
level trigger
Actually overhead is almost zero, the real problem is in non-equivalent
load distribution between processes.
As https://lwn.net/Articles/542629/ mentions -
"At Google, they have seen a factor-of-three difference between the
thread accepting the most connections and the thread accepting the
fewe
Hi,
This patch adds and hw.ixgbe tree and adds rxd/txd. These are already
tunables but it wasn't easy to see if these were being set.
I'd like to commit this soon.
Thanks!
-adrian
adrian@freebsd-10-hack2:~/work/freebsd/head/src/sys/dev/ixgbe % svn diff .
Index: ixgbe.c
===
On 22 July 2013 14:26, trafdev wrote:
> Actually overhead is almost zero, the real problem is in non-equivalent load
> distribution between processes.
> As https://lwn.net/Articles/542629/ mentions -
> "At Google, they have seen a factor-of-three difference between the thread
> accepting the most
What to do when you don't trust the interface? VMWare is obviously
emulating the hardware and their interpretation of what the hardware "is"
is possibly different from ours.
If I boot single-user and tcpdump the interface, I see two transmitted
solicitations. The kernel claims to have sent one.
yep, FreeBSD 9.1-RELEASE-p3
On Mon Jul 22 21:05:55 2013, Adrian Chadd wrote:
On 22 July 2013 14:26, trafdev wrote:
Actually overhead is almost zero, the real problem is in non-equivalent load
distribution between processes.
As https://lwn.net/Articles/542629/ mentions -
"At Google, they have s
On Tue, Jul 23, 2013 at 8:44 AM, Zaphod Beeblebrox wrote:
> What to do when you don't trust the interface? VMWare is obviously
> emulating the hardware and their interpretation of what the hardware "is"
> is possibly different from ours.
>
> If I boot single-user and tcpdump the interface, I see
Sweet, have any code you can share that can elicit this?
I'm writing a network / disk application layer right now so i can
model/test this stuff out. I'd love to see some pointers/example code.
Thanks!
-adrian
___
freebsd-net@freebsd.org mailing list
eg:
* one process, one listen thread, multiple dispatch threads?
* n processes, one listen FD per process, all listening on the same IP:port?
* one process, each thread listening on the same IP:port?
* something else?
Thanks,
-adrian
___
freebsd-net@
13 matches
Mail list logo
