correct. In such case, a modified api should not require to set the ip_hdr total_length field, which is 16 bits. The HW will assign the correct packet length for each transmitted IP packet which is l3_len+l4_len+mss (except of the last segment which may be smaller than mss).
Sim On Sun, Jan 4, 2015 at 11:57 AM, Alex Markuze <alex at weka.io> wrote: > > > On Sun, Jan 4, 2015 at 10:50 AM, Helmut Sim <simhelmut at gmail.com> wrote: > >> Hi Alex and Olivier, >> >> Alex, I made the test and the segmentation is not at the IP level (i.e. >> each packet ip total length indicated the mss length), hence the 16 bits >> total length limitation is not relevant here. >> > > Oliver thanks for reporting back, this is interesting but doesn't come as > a surprise as the headers must be correct when on the wire, what I couldn't > tell you is what happens with the identificayion/Frag off fields. > > The IP length limitation comes from the send side network stack, > theoreticaly Its possible to send a packet of any size as long as your > network stack doesn't mind sending a packet with a malformed IP header(as > the length field is not defined). > . > The send side HW recieves a single packet with the ip length of the whole > packet. Assuming that the ixgbe HW takes the packet len for its TSO > fragmentation from the TX descriptor rather then from the IP header, it > should be able to send as much as the HW supports. > > >> I went over the 82599 datasheet and as Olivier mentioned it is a 18 bits >> field, hence allowing up to 256KB length. >> >> Olivier, although tcp window size field is 16 bits the advertised window >> is typically higher than 64KB using the TCP window scaling option (which is >> the common usage today). >> >> Hence I think that the API should allow at least up to 256KB packet >> length, while finding a solution to make sure it also support lower lengths >> for other NICs. >> >> Any idea? >> >> Sim >> >> On Wed, Dec 17, 2014 at 3:02 PM, Olivier MATZ <olivier.matz at 6wind.com> >> wrote: >> >>> Hi Helmut, >>> >>> On 12/17/2014 08:17 AM, Helmut Sim wrote: >>> >>>> While working on TSO based solution I faced the following two questions: >>>>>>>> >>>>>>>> 1. >>>>>>>> is there a maximum pkt_len to be used with TSO?, e.g. let's say if >>>>>>>> seg_sz >>>>>>>> is 1400 can the entire segmented pkt be 256K (higer than 64K) ?, >>>>>>>> then >>>>>>>> the >>>>>>>> driver gets a list of chanined mbufs while the first mbuf is set to >>>>>>>> TSO >>>>>>>> offload. >>>>>>>> >>>>>>> >>> I think the limitations depend on: >>> >>> - the window size advertised by the peer: your stack should handle this >>> and not generate more packets that what the peer can receive >>> >>> - the driver: on ixgbe, the maximum payload length is 2^18. I don't know >>> if there is a limitation on number of chained descriptors. >>> >>> I think we should define a way to know this limitation in the API. Maybe >>> a comment saying that the TSO length should not be higher than 256KB (or >>> fix it to 64KB in case future drivers do not support 256KB) is enough. >>> >>> Regards, >>> Olivier >>> >>> >> >
