linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: dsaxena@mvista.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Alan Shih: "TCP IP Offloading Interface"
Date: Mon, 14 Jul 2003 17:45:38 -0400	[thread overview]
Message-ID: <3F132482.3090806@pobox.com> (raw)
In-Reply-To: <20030714212222.GA21569@xanadu.az.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




  reply	other threads:[~2003-07-14 21:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-14 18:46 David griego
2003-07-14 19:02 ` Jeff Garzik
2003-07-14 21:22   ` Deepak Saxena
2003-07-14 21:45     ` Jeff Garzik [this message]
2003-07-15  5:27     ` Werner Almesberger
2003-07-14 19:42 ` Alan Cox
2003-07-14 19:14 David griego
2003-07-14 19:26 ` Jeff Garzik
2003-07-15 12:42   ` Jesse Pollard
2003-07-14 19:46 ` Alan Cox
2003-07-14 19:43 David griego
2003-07-14 20:03 ` Jeff Garzik
2003-07-14 20:23   ` Alan Cox
2003-07-14 20:05 ` Alan Cox
2003-07-14 20:30   ` Shawn
2003-07-15  5:58   ` Werner Almesberger
2003-07-14 20:19 David griego
2003-07-14 20:31 ` Alan Shih
2003-07-14 20:34 ` Alan Cox
2003-07-14 21:53   ` Deepak Saxena
2003-07-17 22:31     ` Bill Davidsen
2003-07-14 20:23 David griego
2003-07-14 20:29 David griego
2003-07-14 21:51 David griego
     [not found] <Sea2-F66GGORm1u51rM00012573@hotmail.com>
2003-07-15 11:18 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F132482.3090806@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=dsaxena@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: Alan Shih: "TCP IP Offloading Interface"' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).