I thought LSO would be more likely to be used by TCP, rather than UDP.   
So maybe the small packets you see getting LSO are the TCP control 
frames, whereas the larger UDP frames aren't benefiting?

I've not looked at the LSO implementation in Solaris, just 
hypothesizing.... trying a TCP protocol (e.g. scp) might be interesting.

    -- Garrett

Tom Chen wrote:
> Lucy,
>
> My code is virtually the same.
>
> static boolean_t
> qla_m_getcapab(void *arg, mac_capab_t cap, void *cap_data)
> {
>       int ret = B_FALSE;
>       uint32_t cksum =0;
>       adapter_state_t *ha = (adapter_state_t *)arg;
>       mac_capab_lso_t *cap_lso;
>
>       QL_PRINT(DBG_GLD,("%s(%d) entered\n",__func__,ha->instance));
>       
>       switch (cap) {
>       case MAC_CAPAB_HCKSUM: 
>       ........................
>               break;
>       //LSO
>       case MAC_CAPAB_LSO: 
>               cap_lso = (mac_capab_lso_t *)cap_data;
>               if (ha->cfg_flags & CFG_LSO)
>               {
>                       cap_lso->lso_flags = LSO_TX_BASIC_TCP_IPV4;
>                       cap_lso->lso_basic_tcp_ipv4.lso_max = QLA_LSO_MAX;//max 
> is 65536
>                       ret = B_TRUE;
>               } 
>               break;
>       }
>       return ret;
> }
> To test, I use a Linux machine to get a big file from the Solaris server 
> running my GLDv3 driver. I am using ftp protocol. 
> I noticed that very few big packets (1500 bytes) required hardware to do 
> LSO/TSO offloading, most just IPv4 full checksum offloading only. Ironically, 
> lots of small packets, like the one below which is only 66 bytes long is 
> required to do both LSO and Full IPv4 checksum offloading. So, I feel very 
> strange. 
>
> Another issue is that I use 
> hcksum_retrieve( (mp, NULL, NULL, &start,&stuff, &stop, &mss, &pflags); 
> to get  mss and it is always 0x5a8. Is this correct?
>
> Aug  6 16:04:44 [ID 393812 kern.notice]        requested sending data:
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000000 : 00 30 48 63 ee 
> 0c 00 c0
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000008 : dd 07 4f 67 08 
> 00 45 00
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000010 : 11 2c 2a 5a 40 
> 00 40 06
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000018 : 00 00 c0 a8 0a 
> 32 c0 a8
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000020 : 0a 01 58 bf c0 
> e9 14 c7
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000028 : c9 b1 7d b3 18 
> 2a 80 18
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000030 : c0 50 00 00 00 
> 00 01 01
> Aug  6 16:04:44 [ID 239987 kern.notice] 0x0000000000000038 : 08 0a 00 01 f5 
> c5 01 99
> Aug  6 16:04:44 [ID 498692 kern.notice] 0x0000000000000040 : 0c c5
> Aug  6 16:04:44 [ID 547160 kern.notice] total requested sening data length 
> is: 66
> Aug  6 16:04:44 [ID 310828 kern.notice] hcksum_retrieve( ) returns start=48, 
> stuff=ffffff00,stop=3ab3040, mss=5a8,requested offload=0x14 (LSO and IPv4 
> full checksum offloading)
>
> Tom
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>   

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to