> On Tue, 13 Apr 1999, jamal wrote:
>
> >somewhere like linuxmama.com? Why in hell should i be
> >running a few extra opcodes per TCP packet (in the fast path of all
>
> Because you can't notice it. And you are not running some extra opcode per
> TCP packet but only per retransmitted TCP packet. At least the solaris
> workaround is in a slow path (packet retransmit code) and it can't really
> harm performances. About the enlarging of the kernel of some byte (not
> kbyte),
I think you are missing the point.
It really doesnt matter where in the code you put your fix.
The issue is why is this acceptable? Why is your patch in the kernel
proper?
Where do you draw the line? For example:
Did you know that most windows machines are *not* capable of 3 dupack
generation? The maximum i have see is 2 dupacks (maybe MS has fixed that
now, but not in the environment i am in). In essence, when you use them as
a client; a lost packet means a transmit timeout.
So are you willing to put a hack in there for this MS problem since there
are a lot of Windows clients (more than solrais boxes) which will visit
Linux servers?
I think this has to stop. Linux is mature enough to not care about this
little issues. There are a lot of 'unofficial' patches servers -- this is
where such patches belong
> well if you care about it you should first care about everything
> else ;).
>
Like what?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/