Peter Memishian writes: > > If you were hoping that TCP checksums would protect against (say) DMA > > errors between the network device and the stack itself, that > > protection is disabled by off-load. The trade-off you get is not > > having to waste CPU time looking at every byte against the > > unlikelihood of such (system design) errors. > > So does this argue for having a supported mechanism for disabling checksum > offload? I ask because we were recently talking about how to revise dladm > to indicate whether capabilities like checksum offload are supported on a > given link, and at the time it wasn't clear to me that having a facility > for disabling capabilities was a good idea.
Maybe. I suppose the issue is how much trust the user places in each of these data paths. It isn't as though the risk can ever be reduced to zero, but perhaps the concern about some of those internal data paths isn't exactly unfounded on some platforms. If there were such a facility, I'd probably expect it to work on an interface-by-interface basis. I don't see a reason to try harder than that. > My concern was that having a first-class mechanism for disabling them > would be tantamount to saying that all possible combinations are supported > -- but I'm not convinced that's feasible. Further, I believe for most > capabilities (e.g., LSO or MDT), you'd only want to disable them as a > workaround for a bug or as a debugging aid, for which /etc/system seems to > have the appropriate level of "skank". Yep. Treating any such corruption as a system flaw that has to be fixed sounds much better to me. I don't know, though, what users make of those risks. Their belief in our collective ability to avoid bugs might differ. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 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]
