Re: which kind of driver to design for AoE protocol?
- From: "KOOLER" <anton@xxxxxxxxxxxxxxxxxx>
- Date: 25 Aug 2006 19:27:47 -0700
Sven,
1) There's one weak place inside your theory. Making it completely
useless however... You
silently assume you have storage stack 100% loaded with requests all
the time. However in a real word you would not get such a situation
unless you're running some synthetic test (even a huge file copy is NOT
falling to this case). With your idea of having requests distributed to
the different threads you'll have a pipeline. Pretty long one. With a
request sitting at every single stage of the pipe you'll have
everything working quite well. But make a load pulsating and...
Performance would be simply missing! Do you understand what I mean? How
would you workaround this?
2) Well... We do have working ATA-over-Ethernet driver shipping. And it
took around 6-8 months to have it up and running (and we still have
issues with performance on some of the NICs as NDIS miniport drivers
are not pretty much the same). And we had working iSCSI initiator
before we've add AoE support to it. So I don't think anybody could have
solid driver like this in a few weeks. Unless he has all the pieces of
the puzzle (working and tested SCSI port driver, working at tested raw
ethernet driver and so on) and very good understanding of how final
picture should look like.
Anton
sven.kreamer@xxxxxxxxx писал(а):
KOOLER wrote:
You have to process as many requests at raised interrupt level as you
can. If you'd queue SRBs to PASSIVE_LEVEL worker in some way just b/c
it's easier to implement such a model - it would be a engineering
failure... You would not get adequate performance if you'd exploit
context switches, memory copy operations etc etc etc.
Obviously there are wrong ways of doing things like memory copies,
context switches, and etc's. However, if you are able to efficiently
distribute processing across different threads of execution in an
overlapped fashion, then no matter what you are doing you stand to
enhance performance. For instance, having worker threads running at the
same time on different cpu cores could outrun a simplistic design
trying to process each request in a linear, sequential mode at raised
IRQL. In the past, drivers have been very concerned about overlapping
I/O operations. Now it is more important than ever to optimize
overlapping of CPU operations to really make things fly. Instead of
running things through an assembly line of 5 sequential steps, you do
all 5 steps at the same time to the greatest possible extent. Alas,
Intel will have 100 cores per cpu within 10 years but just 2 can make a
great performance advantage if you use them right.
Anyway, I guess the OP has been scared away by now. He is led to
believe it will take years and there are failures waiting at every
turn. It's kind of true I guess, but meanwhile about everyone
commenting knows they could get a solid driver up and running within a
few weeks.
.
- References:
- Re: which kind of driver to design for AoE protocol?
- From: Don Burn
- Re: which kind of driver to design for AoE protocol?
- From: soviet_bloke
- Re: which kind of driver to design for AoE protocol?
- From: sven . kreamer
- Re: which kind of driver to design for AoE protocol?
- From: KOOLER
- Re: which kind of driver to design for AoE protocol?
- From: sven . kreamer
- Re: which kind of driver to design for AoE protocol?
- Prev by Date: usb device failed to start after the system resumed from hibernation
- Next by Date: Re: which kind of driver to design for AoE protocol?
- Previous by thread: Re: which kind of driver to design for AoE protocol?
- Next by thread: Re: which kind of driver to design for AoE protocol?
- Index(es):
Relevant Pages
|
