IMHO, there are several cases for some type of TCP/IP offload. One is for
embedded systems that are just not capable of doing 1Gbps+. Another is with
10GbE, even high end servers will not be able keep up with TCP
processing/data movement at these speeds. Not being proactive in adopting
TCP/IP offload will force Linux into accepting some scheme that will not
necissarily be best.
>Alan Shih wrote:
>>Has anyone worked on a standard interface between TOE and Linux? (ie.
>>something like Trapeze/Myrinet's GMS?)
>>
>>Or TOE is a forbidden discussion? Any effort in making Linux the OS for
>>TOE at all even though Linux is a little too heavy for it?
>
>
>
>I do not forsee there _ever_ being a TOE interface for Linux.
>
>
>It's not a forbidden discussion, but, the networking developers tend to
>ignore people who mention TOE because it's been discussed to death, and
>no evidence has ever been presented to prove it has advantages where it
>matters, and it has significant _dis_advantages from the get-go.
>
>
>I really should write an LKML FAQ entry for TOE.
>
>
> Jeff
>
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
David griego wrote:
> IMHO, there are several cases for some type of TCP/IP offload. One is
> for embedded systems that are just not capable of doing 1Gbps+. Another
> is with 10GbE, even high end servers will not be able keep up with TCP
> processing/data movement at these speeds. Not being proactive in
> adopting TCP/IP offload will force Linux into accepting some scheme that
> will not necissarily be best.
How does one evaluate a TOE stack to be sure that all the security fixes
in Linux are also in that stack?
How does one evaluate a TOE stack to be sure it doesn't add new security
holes that Linux never had?
Jeff
On Llu, 2003-07-14 at 19:46, David griego wrote:
> IMHO, there are several cases for some type of TCP/IP offload. One is for
> embedded systems that are just not capable of doing 1Gbps+. Another is with
My fridge doesn't need to do 10Gbit a second, and for most other
embedded the constraints are ram bandwidth and nothing else. Since
deeply embedded stuff also doesn't run with MMUs or runs 'partially
trusted' most of the VM games and the socket api games also go away.
I've done deeply embedded tcp/ip. I don't buy the argument, embedded
gains the least of all from ToE.
> 10GbE, even high end servers will not be able keep up with TCP
> processing/data movement at these speeds. Not being proactive in adopting
They said that about 10Mbit until Van showed them a thing or two. They
said it about 100Mbit, they said it about gigabit.
> TCP/IP offload will force Linux into accepting some scheme that will not
> necissarily be best.
TCP/IP is an exercise in two things when you are running at speed
1. Finding the memory bandwidth - ToE doesn't help, checksums do,
sg does, on card target buffers do with decent chipsets.
2. Handling in order perfectly predicted data streams. ToE is
overkill for this. Thats about latency to memory and touching
as little as possible. The main CPU has a rather good connection
to main memory.
ToE is also horribly vulnerable to attack because putting it on a card
dictates relatively low CPU power and low power consumption as well as
rather nasty pricing issues. Historically low power devices have
repeatedly been screwed by attackers hitting software or other slow
paths in the device to attack it.
This is before we get into the delights of multipath routing across
different vendors cards, firewalling, traffic shaping, retrofitting new
features, questions about what happens with an old ToE card when its
got a hole...
The internet land speed record is held by a non ToE system, let me know
when that changes.
On Jul 14 2003, at 15:02, Jeff Garzik was caught saying:
> David griego wrote:
> >IMHO, there are several cases for some type of TCP/IP offload. One is
> >for embedded systems that are just not capable of doing 1Gbps+. Another
> >is with 10GbE, even high end servers will not be able keep up with TCP
> >processing/data movement at these speeds. Not being proactive in
> >adopting TCP/IP offload will force Linux into accepting some scheme that
> >will not necissarily be best.
>
>
> How does one evaluate a TOE stack to be sure that all the security fixes
> in Linux are also in that stack?
>
> How does one evaluate a TOE stack to be sure it doesn't add new security
> holes that Linux never had?
I just replied to Jeff privately regarding this on a side thread, but
here it is again:
My question back is how do you evaluate a high-end SCSI RAID controller
to make sure that there is no bug in the firmware that causes you to loose
all your data? You test it and if it fails miserably, you go yell at the
HW manufacturer. There's no argueing that the question needs to be answered
b/c opening up a security hole is a dangerous thing to do, but perhaps some
sort of standardized test could be developed by the community, HW vendors,
and OSDL? I agree that TOE has problems and many of the points addressed
by others in this thread are valid concerns, but simply saying that
because of these issues "TOE will never happen" or "TOE is Evil" is not
going to make the desire of TOE from HW vendors go away. There needs to
be an open discussion between HW vendors and the community to determine
the best way to move forward. This includes addressing questions such as
do we want TOE + non-TOE stacks running at the same time? (I propose
a big no for that since the level of complexity has just increased
many times). Do we want to support multiple TOEs? How do we handle
routing between TOEs? Etc... We either need to start thinking about
these issues now or we'll be stuck with crap implementation requirements
due to already existing TOE support in other OSes. In a perfect academic
world TOE might be a horrid idea that should die, but the HW vendors have
already decided to move in this direction? How is linux going to react to
this: Just ignore it until it's too late or be pro-active about it?
A minimum step would be moving in the direction of FreeBSD and providing
hooks for alternate stacks. That way if an embedded developer wanted
to provide a different stack, he could do so and take full responsibility
for supporting that kernel.
Finally, I would like to point out that just b/c something is considered
bad does not preclude it from being in the kernel. I think most kernel
developers agree that PAE, I2O, ISAPNP and other technologies are broken
and we wish they would die, yet Linux still supports them. Why? B/C the
HW requires it. TOE is going to be no different.
~Deepak
--
Deepak Saxena
MontaVista Software - Powering the Embedded Revolution - http://www.mvista.com
Deepak Saxena wrote:
> My question back is how do you evaluate a high-end SCSI RAID controller
> to make sure that there is no bug in the firmware that causes you to loose
> all your data? You test it and if it fails miserably, you go yell at the
> HW manufacturer. There's no argueing that the question needs to be answered
Hardware RAID is not remotely accessible to the entire world.
> and OSDL? I agree that TOE has problems and many of the points addressed
> by others in this thread are valid concerns, but simply saying that
> because of these issues "TOE will never happen" or "TOE is Evil" is not
> going to make the desire of TOE from HW vendors go away. There needs to
> be an open discussion between HW vendors and the community to determine
> the best way to move forward. This includes addressing questions such as
> do we want TOE + non-TOE stacks running at the same time? (I propose
> a big no for that since the level of complexity has just increased
> many times). Do we want to support multiple TOEs? How do we handle
> routing between TOEs? Etc... We either need to start thinking about
Answering those questions implies that TOE is a good idea. That still
is still an open question.
The community has been _trying_ to dialogue with people interested in a
progressive solution that actually addresses the problems we raise. I
haven't seen a single response.
I don't see any dialogue at all. The examples I have seen so far are HW
vendors saying "we are doing TOE" not "should we be doing TOE?"
DaveM has been dropping ever-more-blatant hints about an efficient
design. Who has listened?
> these issues now or we'll be stuck with crap implementation requirements
> due to already existing TOE support in other OSes. In a perfect academic
> world TOE might be a horrid idea that should die, but the HW vendors have
> already decided to move in this direction? How is linux going to react to
> this: Just ignore it until it's too late or be pro-active about it?
Not all hardware vendors. One specific hardware vendor, with decades of
experience in TCP/IP and Unix, realizes that TOE is not the answer.
> A minimum step would be moving in the direction of FreeBSD and providing
> hooks for alternate stacks. That way if an embedded developer wanted
> to provide a different stack, he could do so and take full responsibility
> for supporting that kernel.
This is trivial. Just create your own character device driver and go to
town.
> Finally, I would like to point out that just b/c something is considered
> bad does not preclude it from being in the kernel. I think most kernel
> developers agree that PAE, I2O, ISAPNP and other technologies are broken
> and we wish they would die, yet Linux still supports them. Why? B/C the
> HW requires it. TOE is going to be no different.
TOE is vastly different.
As Alan said, nobody is stopping developers from maintaining their own
TOE fork of Linux. Under Linux, forks are _encouraged_, remember.
Jeff
Deepak Saxena wrote:
> My question back is how do you evaluate a high-end SCSI RAID controller
> to make sure that there is no bug in the firmware that causes you to loose
> all your data?
This may be a great moment for relaxing with a good book, e.g. Bruce
Schneier's "Secrets & Lies", chapter 22, where he describes why
functional testing and discovering security bugs are so different.
> Finally, I would like to point out that just b/c something is considered
> bad does not preclude it from being in the kernel.
Well, in the case of TOE, we should at least be able to politely ask
all the useless silicon to step aside :-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/