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 attache
How much traffic are you passing during peak times?
--- On Wed, 4/25/12, Sami Halabi wrote:
> From: Sami Halabi
> Subject: Re: Intel 10 GbE cards (ixgbe)
> To: "Takuya ASADA"
> Cc: freebsd-net@freebsd.org, "Marko Zec"
> Date: Wednesday, April 25, 2012, 10:13 AM
> Hi,
> I have it running on fb
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
On Fri, Apr 27, 2012 at 12:29, Sean Bruno 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 keeping packets for t
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 wrote:
> On Fri, Apr 27, 201
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 = mem_alloc(sizeof(SVCXPRT));
>> 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 ma
On 27 April 2012 16:08, David Christensen wrote:
> The intent was to pass compliance tests such as those performed at UNH
> by limiting the MTU to the size allowed by the IEEE 802.3 specification.
> (No one likes explaining such failures to customers.) As you indicate, real
> world applications
