linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Deepak Saxena <dsaxena@mvista.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Alan Shih: "TCP IP Offloading Interface"
Date: Mon, 14 Jul 2003 14:22:22 -0700	[thread overview]
Message-ID: <20030714212222.GA21569@xanadu.az.mvista.com> (raw)
In-Reply-To: <3F12FE4B.2070004@pobox.com>

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 - www.mvista.com

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

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-14 18:46 Alan Shih: "TCP IP Offloading Interface" David griego
2003-07-14 19:02 ` Jeff Garzik
2003-07-14 21:22   ` Deepak Saxena [this message]
2003-07-14 21:45     ` Jeff Garzik
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=20030714212222.GA21569@xanadu.az.mvista.com \
    --to=dsaxena@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).