> It would have been better if the TCP/IP CTC protocol included an exchange > of buffer sizes using a pre-defined small I/O buffer. But it didn't and > that's the way the ball bounces. (The restriction being that the MTU would > be forced to be less than the I/O buffer size.) Exactly. But when a mistake is made, then you need to look for a way to correct it rather than fielding these config problems time & again. It seems like this is a common config issue... and thus it is time for the device driver to fix it... it is just a matter of programming and careful transition to the new driver(s). (E.g. add them as new alternate drivers rather than replacing the old ones, etc.)
And while I'm on the subject... why is it that the IBM proprietary device drivers need to be versioned to the kernel (creating all sorts of havic for those who what to upgrade before IBM is ready or even do their own kernel hacking). There is no reason (other than perhaps some legal bean counter's) to not split that driver code into a sourced layer which implements a private api for the oco portion that contains all the secrets. The api would need (for instance) to present a kernel data structure abstraction which that oco portion could view as fixed... and the sourced piece need hold nothing proprietary... again, simple straight forward programming.... "its time..." Peace. -njg
