Old Synopsis: sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC
New Synopsis: [netinet] [patch] sosend sometimes return EINVAL with TSO and
VLAN on 82599 NIC
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Apr 27
On Thu, Apr 26, 2012 at 03:23:19PM +0400, Andrey Zonov wrote:
Hi,
I found that jumbo frames don't work after r218423 with bce driver.
This happens because controller doesn't do reinitialization when MTU
is changed. Attached patch solves this problem.
Could you verify whether attached
How much traffic are you passing during peak times?
--- On Wed, 4/25/12, Sami Halabi sodyn...@gmail.com wrote:
From: Sami Halabi sodyn...@gmail.com
Subject: Re: Intel 10 GbE cards (ixgbe)
To: Takuya ASADA s...@dokukino.com
Cc: freebsd-net@freebsd.org, Marko Zec z...@fer.hr
Date: Wednesday,
On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote:
Queue splitting in Intel cards is done using a hash of protocol
headers, so this is expected behavior. This also helps with TCP and
UDP performance, in terms of keeping packets for the same protocol
control block on the same core, but for
On Fri, Apr 27, 2012 at 12:29, Sean Bruno sean...@yahoo-inc.com wrote:
On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote:
Queue splitting in Intel cards is done using a hash of protocol
headers, so this is expected behavior. This also helps with TCP and
UDP performance, in terms of
I suspect to do it right would involve having the stack/kernel have more
interaction with the driver/interface data, and this IS the way RSS was
envisioned to work. Its been talked about but hasn't happened so far.
Jack
On Fri, Apr 27, 2012 at 1:00 PM, Juli Mallett jmall...@freebsd.org wrote:
Hi Alex,
I don't want to be demanding, but would you please consider committing
your fixes?
And if you could, would you please do it as a set of commits, one per
'thing', rather than one big monolithic commit that does half a dozen
different things? That way if there are any further regressions,
In an OOM condition, we noticed a couple of mem_alloc handling bugs in
this file. Please let me know if a PR should be opened for these.
- No NULL checks after mem_alloc()'s:
SVCXPRT *
svc_xprt_alloc()
{
SVCXPRT *xprt;
SVCXPRT_EXT *ext;
xprt =
I also don't understand why sysctl hw.bce.loose_rx_mtu doesn't respect
with tunnable hw.bce.strict_rx_mtu. Is there any reason to give them
different names?
It may be an oversight. Personally I don't see any reason except
debugging purpose to limit RX frame size to interface MTU. It makes
