Intel Communities: Message List - Queries on ETI Baremetal framework

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Sat, 03 Sep 2011 02:42:40 GMT

those two bytes are actually the encoding for an instruction that the scc team added to the p54c to

flusht the cache. since its not part of the standard pentium instruction set, gas doesn't really

know about it, so we cheat by issuing the opcode as a byte constant...the processor interprets

it as a flush of all those lines in the L1 which have the MPB bit set

as far as the second bit, i usually set up a reader/writer ring buffer, one for each processor

pair thats going to communicate. a processors sends by writing data into the ring, and

advancing the write pointer. the receiver polls the write pointer, and when it has consumed

the data it advances the read pointer. if the write pointer is up against the read pointer, its

means the writer has filled up the buffer, it needs to block or busy-spin, because the buffer is full.

if the read pointer is at the write pointer, it means the channel is empty. this structure works

without locks because each of the two pointers has exactly one writer and one reader.

if you set up 47 of these channels in each mpb, it means you have only 174 bytes per channel,

which is why we chose to put the messages in dram, so we could send more data between

each polling interval (bandwidth delay product)

obviously there are all sorts of other schemes you could come up with for managing/sharing

the mpb buffer space.

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Sat, 03 Sep 2011 02:23:50 GMT

Sorry but i am still not very clear. what i understand is that the asm statement just defines two bytes.

I am not getting how is it actually causing the mpb to be invalidated.

Also please suggest how to go about polling the mpb for messages.

Thanks

Vaibhav

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Sat, 03 Sep 2011 00:49:21 GMT

the asm statement is called when you are unsure that the values you may have in the L1 cache

represent whats in the underlying memory. typically you would flush at each message boundary,

although i suppose its possible to invalidate only when cycling around to the beginning of a ring

buffer.

scc_find_region just gives you the address for the base of the mpb for some remote processor

as mapped to your core address space. this value doesn't change during the run and should be

cached in some local structure as the implementation of scc_find_region isn't particularily efficient

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Fri, 02 Sep 2011 23:09:29 GMT

Thanks hoffman for the reply! But I am not clear

about the the invalidate function.Could you please explain a little how the asm statement is

causing cache invalidation ? Also , should the scc_find_region be used for polling the mpb as well ?

-Thanks

Vaibhav

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Fri, 02 Sep 2011 19:26:51 GMT

well, in ETI land, assuming you are doing polling, all you'd need to do is run

memory_region m;

scc_find_region(MEMORY_REGION_MPB, target, &m)

where m is defined in memory_region.h, and target is the name of the remote node.

m will contain a pointer in your address space to that node's 8k MPB base.

static inline void invalidate_l1_mpb()
{
__asm__ volatile ( ".byte 0x0f; .byte 0x0a;\n" );
}

would then be used to flush the lines with the MPB tag

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Fri, 02 Sep 2011 17:03:56 GMT

Actually right now my aim is to gain a better understanding of the system and of the tradeoffs involved in message-passing(such as dram vs mpb).

So to begin with I was thinking of implementing few simple baremetal applications which can use mpb for message passing.

This is basically primitive work. So I was hoping to get some directions and may be some sample code so that I can get started.

I am not looking into running benchmarks and collecting statistics right now (though it might come at a later stage).

Thanks

Vaibhav

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Fri, 02 Sep 2011 15:37:23 GMT

it should be pretty straightforward to use the '-r' mode and set up ring buffers in the mpbs

in order to run benchmarks. is it acceptable to poll for message arrival, or would you prefer

to use asynchronous interrupts?

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Fri, 02 Sep 2011 12:56:26 GMT

I am interested in looking at the messaging performance and don't care much about MPI.

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Wed, 31 Aug 2011 17:33:22 GMT

with the -r option, the messaging that the ETI software uses doesn't use the MPBs, you're free to

play with them as you like. which implies you'd need to write your own messaging layer in

order to use them.

it would be possible to add another mode which drastically reduces the MPI mtu and

allocates the message buffers out of the MPB space. we dont really have alot of resources

to do this, but are looking at various options for ongoing support of the software, so implementing

this is a possiblity

how important is the MPI layer to your work? or are you just interested in looking at messaging

performance?

Re: Queries on ETI Baremetal framework

webadmin@intel.com — Wed, 31 Aug 2011 16:55:39 GMT

Hi hoffman,

I wish to experiment with message passing entirely using mpb. Can you please suggest how to proceed after

using the -r option. The user manual says that after using -r MPI and streams are unavailable.

-Thanks