Kacheong Poon writes: > For example, suppose we want to use the TCP MD5 option. I > think it will work nicely with MDT. But I don't know if there > is (or ever will be?) a hardware out there doing LSO which can > fill in the MD5 option value. As another example, MDT can > support the ECN nonce in RFC 3168 nicely. I doubt that there > is a hardware out there doing LSO that can do ECN nonce.
Yep, and, as I mentioned, IPsec is pretty problematic with LSO, but "easy" with MDT. I'm not a fan of letting drivers synthesize packet headers. We've been down this "TCP/IP offload" path multiple times in decades past, and it always ends up hurting. (Not that this seems to stop or even slow down LSO advocates ...) The big problem with MDT is that the implementation uses many extra code paths and loops scattered over the code base. It's invasive in the stack itself, much in the same way that CGTP adds complexity. That makes it harder to support and less well tested. > Anyway, I think MDT will go away as most people think that > protocol won't evolve... The point of MDT was to amortize cost. If you can make the downward calls cheap enough -- if GLDv3 finally pays off for third party drivers -- then I think that problem mostly goes away. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
