On Jun 5, 2008, at 2:20 AM, Yunsong (Roamer) Lu wrote: > You are saying that the MDT can handle IP fragmentation not only for > UDP, but also for other types of transport, right? Has the possible > use of MDT that you mentioned been deployed? If so, probably we need > to handle it accordingly.
I was referring to UDP/IP fragmentation as an example, but the original intention for MDT was to have a generic mechanism for handing off a batch of packets (regardless of its contents) across Streams modules, whose headers and payloads span across virtually contiguous chunks of memory. (It predates GLDv3 and even FireEngine itself to some extent.) As others have said, offloading UDP/IP fragmentation is rather questionable in terms of real-world use cases; if there was any such use for MDT in the past, it was because of convenience. MDT itself has nothing to do with IP fragmentation. > > I think it's better not to generalize the interface for non-UDP > traffic, since "generalizing things often brings added complexity" > as you said. The IP fragmentation part of LSO should focus on UDP, > since it's supported popularly by today's NICs. What's your opinion? It depends on the intention of this "soft LSO"; if it can also include amortizing the costs of DMA setup/teardown, that would be great. If it can be further extended to be generic, and not specific to TCP and UDP/IP fragmentation, it would even be better. (Just some history: the original concept of MDT was as simple as chaining a bunch of M_DATA mblks and marking them with some flags, indicating that they belong to a special group and that they be processed differently across the stack. This quickly became a nightmare as things were no longer tractable -- there were issues related to foreign modules inserted between IP and the driver, and that using M_DATA type itself would break lots of code due to the assumptions about the contents of the mblk; hence M_MULTIDATA. The accessors were added to hide the underlying data structures, so that they can be changed without breaking modules/drivers. I wish the PSARC cases would be open such that others can read the materials I provided there, which contained a lot of details about the design decisions.) Note that I'm not pushing for MDT to continue to exist in its current form; I'm just questioning the goal behind "soft LSO". If it is to replace MDT, then is it a full replacement of the functionalities, or just a subset related to TCP LSO? If it is otherwise, then it should be indicated as such, for clarity. Adi > > > Thanks, > > Roamer > > > > Adi Masputra wrote: >> Roamer, >> On May 30, 2008, at 6:12 PM, Yunsong (Roamer) Lu wrote: >>> Frank, >>> The current LSO implementation in Solaris is only for TCP. MDT was >>> implemented with both TCP and UDP. But the plan is to implement >>> UDP LSO >>> and to EOL MDT in the near future, so you may consider whether to >>> support UDP LSO on your hardware. >> One thing to keep in mind, as far as UDP goes, is that there is a >> difference >> between UDP Fragment Offload and MDT; the latter is generic, and >> is not specific >> to transmitting UDP/IP fragments. One of the possible things that >> we thought >> would be nice is to utilize MDT to transmit a group of small, pre- >> packetized >> UDP/IP datagrams (non-fragments) that may be originated from >> disk. IIRC at >> some point during Yosemite project there was a prototype of some >> sort involving >> a sendfile-like interface and a modified Darwin Streaming Server. >>> The software interface for UDP LSO will be similar to TCP LSO but >>> slightly different since IP fragmentation instead TCP >>> segmentation will >>> be done by the hardware. >> See above; if you plan on extending the "soft LSO" to include >> generic types >> of payloads, then you might want to consider such a scenario >> during design. >> MDT was an attempt for a generic framework, but generalizing >> things often >> brings some added complexity. >> I'm in full support for a better and simpler design; but I have yet >> to see >> any concrete design discussions or documents for a replacement >> (unless I've >> missed it). >> Adi >>> >>> Thanks, >>> >>> Roamer >> _______________________________________________ >> 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]
