Hi guys,
The problem of ftp failure turns out that, if the payload is padding data, then
the payload can not be linked by b_cont of packet header mblk.
Look the packet below again which was received by the ftp server: the first 54
were sent from ftp client during the negotiation period, the extra 6 zeros in
the payload buffer were padding data which were added automatically by sending
NIC to make the whole tx packet length more than the minimum ethernet packet
length, 60 bytes. This is correct packet and the split of header from payload
is ok also.
However, somehow in Solaris, padding data mblk_t must not be linked by b_cont
of header mblk_t, it must be copied to the end of header and sent together with
header, otherwise, this packet is dropped. But, if the payload is real packet
data, not padding bytes, then it can be linked by b_cont.
Jun 4 18:11:08 euclid qlge: [ID 276442 kern.notice] Header of 54 bytes in
header buffer.
Jun 4 18:11:08 euclid qlge: [ID 858336 kern.notice] RX packet header dump:
Jun 4 18:11:08 euclid qlge: [ID 239987 kern.notice] 0x0000000000000000 : 00 c0
dd 12 01 58 00 c0
Jun 4 18:11:08 euclid qlge: [ID 239987 kern.notice] 0x0000000000000008 : dd 0a
b1 50 08 00 45 00
Jun 4 18:11:08 euclid qlge: [ID 239987 kern.notice] 0x0000000000000010 : 00 28
89 ae 40 00 40 06
Jun 4 18:11:08 euclid qlge: [ID 239987 kern.notice] 0x0000000000000018 : d9 76
c0 a8 2b 28 c0 a8
Jun 4 18:11:08 euclid qlge: [ID 239987 kern.notice] 0x0000000000000020 : 2b 32
8b f7 00 15 96 cd
Jun 4 18:11:08 euclid qlge: [ID 239987 kern.notice] 0x0000000000000028 : 57 3f
04 6f dd 75 50 10
Jun 4 18:11:08 euclid qlge: [ID 887868 kern.notice] 0x0000000000000030 : c1 e8
ba 42 00 00
Jun 4 18:11:08 euclid qlge: [ID 752611 kern.notice] 6 bytes in payload buffer
Jun 4 18:11:08 euclid qlge: [ID 969143 kern.notice] RX payload dump:
Jun 4 18:11:08 euclid qlge: [ID 887868 kern.notice] 0x0000000000000000 : 00 00
00 00 00 00
After we splited header and payload, then copy header to a 2 byte boundary
address which makes the IP header on a 4 byte boundary (as suggested by Garrett
and Rao), then the performance on Sparc is improved by > 35%!
However, this solution does not help on x86, sigh. We still need to further
investigate other issues affecting throughput.
Tom
----- Original Message -----
From: "Andrew Gallatin" <[email protected]>
To: "tom60" <[email protected]>
Cc: "Paul Durrant" <[email protected]>; <[email protected]>;
<[email protected]>
Sent: Monday, June 08, 2009 6:58 AM
Subject: Re: [driver-discuss] GLD3 NIC driver performance tuning
> tom60 wrote:
>> Paul,
>>
>> Our adapter can put the whole tcp/udp header is in one segment of buffer
>> and payload in another, we just use b_cont to link them up.
>> Theoretically, this should work.
>> We have used snoop&netperf to exam the packets sent to OS, they can read
>> these split header packets correctly. So, I think it is a "bug" in
>> Solaris ftp application and possibly other similar network applications
>> that does not process this kind of split header packets correctly.
>>
>> But I do not quite understand why 66? the first 66 must be in one
>> segment? is this number good for all packets?
>
> 66 is the size of ethernet + IP + TCP headers, assuming TCP timestamps.
> From what you've said, it sounds like your hardware is already
> doing this.
>
> Did you try following the packet with dtrace?
>
> Drew
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
