On Mon, Apr 8, 2013 at 1:14 PM, Duvvuru,Venkat Kumar <
venkatkumar.duvv...@emulex.com> wrote:
> Hi,
> In the transmit path, if enqueue mechanism is used instead of blocking on
> the lock, the throughput is not good in some scenarios (especially single
> queue, multiple connections).
> For example:
Hey Andre,
Looks OK to me.
Note that tcps_rcvdwhileclosing is a new stat Juan added (I had omitted the
rest of that diff b/c adding a new stat wasn't that interesting to the
discussion). If you want that stat added, we can prepare a patch with the
rest of the changes (or, I'm sure you know alrea
On 8 April 2013 10:14, Duvvuru,Venkat Kumar
wrote:
> Hi,
> In the transmit path, if enqueue mechanism is used instead of blocking on the
> lock, the throughput is not good in some scenarios (especially single queue,
> multiple connections).
> For example:
> if (TRY_LOCK(&wq->tx_lock)) {
>
Hi,
In the transmit path, if enqueue mechanism is used instead of blocking on the
lock, the throughput is not good in some scenarios (especially single queue,
multiple connections).
For example:
if (TRY_LOCK(&wq->tx_lock)) {
status = oce_multiq_transmit(ifp, m, wq);
UNLOCK(&
Sephe,
On Sat, Apr 06, 2013 at 06:04:25PM +0800, Sepherosa Ziehau wrote:
S> Hope the following analysis helps; IMHO, the reporter probably had hit
S> the same bug:
S>
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/1ff9b7d322dc5a26f7173aa8c38ecb79da80e419
Thanks for hint! The commit me
On 05.04.2013 13:09, Matt Miller wrote:
Hey Rick,
I believe Juan and I have root caused this crash recently. The t_state =
0x1, TCPS_LISTEN, in the link provided at the time of the assertion.
In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the
socket and we should never
Hi,
The patch in question can be found at
http://people.freebsd.org/~syrinx/snmp/libbsnmp-20121029-01.diff , I am
also attaching it to this e-mail. I didn't commit it yet, since I did not
manage to get it properly reviewed or get confirmation from Harti that it
solved his problem. Error responses
Hello, Harti.
You wrote 8 апреля 2013 г., 15:40:07:
LS>>(1) I have a lot of "could not encode error response" in
LS>>/var/log/messages after change of hardware. It looks like, every
LS>>request from mrtg for "unexistent" interface leads to this message.
LS>>I'll reconfigure mrtg, of course, but i
Hi,
On Sun, 7 Apr 2013, Lev Serebryakov wrote:
LS>(1) I have a lot of "could not encode error response" in
LS>/var/log/messages after change of hardware. It looks like, every
LS>request from mrtg for "unexistent" interface leads to this message.
LS>I'll reconfigure mrtg, of course, but it is ann
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
Synopsis: [tcp] [patch] An error of calculating TCP sequence number will
resault in the machine to restart
State-Changed-From-To: open->analyzed
State-Changed-By: glebius
State-Changed-When: Mon Apr 8 11:01:18 UTC 2013
State-Changed-Why:
Grab the PR. I've reproduced it.
Responsible-Changed-Fro
Synopsis: [patch] [net] Removing an unavailable sysctl from manpage
State-Changed-From-To: open->patched
State-Changed-By: ae
State-Changed-When: Mon Apr 8 10:15:00 UTC 2013
State-Changed-Why:
Committed to the head/. Thanks!
Responsible-Changed-From-To: freebsd-net->ae
Responsible-Changed-By: a
12 matches
Mail list logo
