RE: Major code changes - was RE: [Iometer-devel] Dynamo for OS Xon PPC

[Daniel S. <dan...@ed...>]

Sean,

may I propose the following. I see a lot of great enhancements
and valid points you made here and I think your proposal is the
important first step for the future architecture of Iometer.

But as we have seen in the discussion so far we are raising more
and more points and issues about the code. Even after all the
cleanup we already did, the code is still miles away from where
we wanted it to be. So as much as I value this discussion I fear
that we will come to an point where we have discussed and raised
200 important things to do and get then stuck somewhere there.

We have to structure and coordinate our efforts and to quarantee
a proper continues support of the current Iometer (lets call it
Iometer1) while working on Iometer2 and Iometer3.

Short term (next few weeks) is Iometer1,
middle term (next few months) is Iometer2 and
long term (the time after) is Iometer3.

The topics of Iometer1 and Iometer2 are more or less fixed and
I will write a seperate mail about that and why today. So we
have enough time till Iometer3 (and we should see this as a
gift, not as a delay) to work on a clear specification that has
all the points and their reasons in. As you already did a great
proposal and still have some unreleased stuff on our notebook
I think it makes sense that you continue this work. Here in
iometer-devel we realy should focus then on discussing specific
topics and have one mail thread per topic - otherwise we end
up in a big melting pot.

Best regards,
Daniel



On Wed, 14 Apr 2004 09:38:37 -0700, Hefty, Sean wrote
> > > Things like "processing agents" can be supplied at any time later,
> but I
> > > wanted to ensure that there was a mechanism that could eventually be
> > > used for data validation.  Private worker data buffers are needed
> for
> > > this as well.
> > so here what u want is a mechanism to register some processing
> handlers?
> 
> Correct.  For example, you can touch all memory after an I/O 
> transfer in order to affect the processor cache.  You could also use 
> this to perform other activities, such as registering memory with 
> hardware adapters that provide user-mode access directly to hardware.
> 
> > > "Transports" exist somewhat already as "targets" in the code.  The
> > > existing class structure isn't that far off from the proposed
> modules.
> > > I was picturing being able to add new transports over time once a
> > > generic framework was in place.  Only the existing disk and TCP
> > > transports would need to be migrated.  Again, a goal would be to
> clearly
> > > identify the type of transport being used, so that it becomes clear
> to
> > > users, for example, that a disk transport on Linux uses a memory
> cache,
> > > whereas a disk transport on Windows does not.  This would further
> allow
> > > each transport to be optimized for their platform, rather than
> trying to
> > > fit something like completion ports on all platforms.  What is
> needed is
> > > refinement of the base transport API.
> > can u provide some examples on possible future transports?
> 
> Infiniband and DAPL are the one I'm most interested in.  Infiniband 
> is probably a year away from having a stable API.  I'm hoping for an 
> architecture that allows a user to provide their own transport,
>  which would be easy to develop and change.