Hi Frank,
LRO is not yet supported in the stack, and there will be some other
issues than the b_cont check in IP.
But experimentally LRO implementation in driver works after fixing the
check against maximum 2-block of message. You may apply this *hack* to
try your LRO implementation if you can compile IP module for your
Solaris version.
===
--- old/usr/src/uts/common/inet/ip/ip.c Wed Apr 16 03:39:13 2008
+++ new/usr/src/uts/common/inet/ip/ip.c Wed Apr 16 03:39:13 2008
@@ -13042,12 +13042,7 @@
/* multiple mblks of tcp data? */
if ((mp1 = mp->b_cont) != NULL) {
- /* more then two? */
- if (mp1->b_cont != NULL) {
- IP_STAT(ipst, ip_multipkttcp);
- goto multipkttcp;
- }
- len += mp1->b_wptr - mp1->b_rptr;
+ len = msgdsize(mp);
}
up = (uint16_t *)(rptr + IP_SIMPLE_HDR_LENGTH + TCP_PORTS_OFFSET);
@@ -13349,7 +13344,6 @@
/* Get the total packet length in len, including headers. */
if (mp->b_cont) {
-multipkttcp:
len = msgdsize(mp);
}
===
Thanks,
Roamer
Francesco DiMambro wrote:
> Hi
> I have a working implementation of LRO, it builds a b_cont list of
> incoming
> packets during the Interrupt service routine, using the LRO rules. Then
> passes
> it up to the stack, once in the Stack IP checks if a the b_cont chain is
> more than
> 2 elements long and if so send it up a 'slow' path which re-calculates the
> checksum. The Packet checksum will be wrong for the LRO chain since the
> checksum is only for the first packet. The stack should be able to
> accept the
> LRO packet based on hardware checksum rules.
> I have limited the LRO chain to 2 elements and with that the stack
> accepts
> the LRO messages in the non fast path, with an improvement in
> performance for
> a simple netperf run of 300Mb/s. I expect if the chain is allowed to be much
> larger the performance will also be much larger, based on Linux
> experience with
> the same algorithm.
> Is there plans to remove this check? and enable hardware checksumming
> for all paths through the tcp/ip stack? That change will enable the software
> implementation LRO?
> If I alter the disassembly to avoid the check is there gotcha's that
> will make
> it fail?
>
> Frank
>
>
>
>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
--
# telnet (650)-786-6759 (x86759)
Connected to Solaris.Sun.COM.
login: Lu, Yunsong
Last login: January 2, 2007 from beyond.sfbay
[EMAIL PROTECTED] v1.04 Since Mon Dec. 22, 2003
[EMAIL PROTECTED] Networking]# cd ..
_______________________________________________
networking-discuss mailing list
[email protected]
