Hello All,
2014-03-27 8:27 GMT+08:00 Rick Macklem :
>
> Well, bumping it from 32->35 is all it would take for NFS (can't comment
> w.r.t. iSCSI). ixgbe uses 100 for the 82598 chip and 32 for the 82599
> (just so others aren't confused by the above comment). I understand
> your point was w.r.t. us
Christopher Forgeron wrote:
> That's interesting. I see here in the r251296 commit Andre says :
>
> Drivers can set ifp->if_hw_tsomax before calling ether_ifattach()
> to
> change the limit.
>
> I wonder if we add your same TSO patch to if_lagg.c before line
> 356's
> ether_ifattach() wil
Christopher Forgeron wrote:
>
>
>
>
>
> On Tue, Mar 25, 2014 at 8:21 PM, Markus Gebert <
> markus.geb...@hostpoint.ch > wrote:
>
>
>
>
>
> Is 65517 correct? With Ricks patch, I get this:
>
> dev.ix.0.hw_tsomax: 65518
>
>
>
> Perhaps a difference between 9.2 and 10 for one of the macro
pyu...@gmail.com wrote:
> On Tue, Mar 25, 2014 at 07:10:35PM -0400, Rick Macklem wrote:
> > Hi,
> >
> > First off, I hope you don't mind that I cross-posted this,
> > but I wanted to make sure both the NFS/iSCSI and networking
> > types say it.
> > If you look in this mailing list thread:
> >
>
Confirmed that adding this to sys/net/if.c fixes the issue for lagg as well
as ixgbe.
660:if (ifp->if_hw_tsomax == 0)
661:ifp->if_hw_tsomax = IP_MAXPACKET - (ETHER_HDR_LEN +
ETHER_VLAN_ENCAP_LEN);
Code before (looks to be introduced in 9.2, r251296 as Rick mentions above)
just
Up for almost 19 hours under load without a single error. I would say the
TSO patch does work, now I'm going to run lagg tests.
The more I think of it, the more I wonder if setting tsomax in if.c at line
660 isn't the better idea, like below.
660:if (ifp->if_hw_tsomax == 0)
661:
... snip ...
>> I'm wondering what's happening on the outbound path, most of your rules
>> handle inbound (to kernel) and it seems that rule 65535 deals with most
>> outbound, except those specifically acting on both paths.
>>
> So do I :)
>
>>
>> Maybe try adding to the above:
>> ipfw add 63510
