[ixp1200] WWBump Code in 'Network System Design'

[Shyamal Pandya]

Hi Lim,
I don't have this book but let me give it a shot.


>1.  alu[dpoff, dpoff, +, 16]  ; Add Ether+TCP offsets
>2.  Buf_GetData[base, dl_buffer_handle] ; Get buffer base address
>3.  DL_GetBufferOffset[boff]  ; Get data offset in buf.
>4.  alu[boff, boff, +, dpoff]  ; Compute byte address
>5.  alu_shf[boff, --, B, boff, >>3]  ; Convert to Q-Word addr.
>6.  sdram[read, $$hdr0, base, boff, 1], ctx_swap ; Read 8 bytes
>
>Assume the packet reach at the IX_Bus interface. [This is a big 
>assumption... and is it correct? If not, when dispatch loop runs the WWBump 
>macro, the entire packet is currently in SDRAM? ]


>From the above code it is pretty clear that the packet is already in the 
SDRAM. There should be code somewhere that handles packet reception and 
transfer from port --> rfifo --> SDRAM. Since it is pretty generic it should 
be provided at one place and then not repeated. The dispatch loop must call 
the Ingress macro which performs the packet reception before it will call 
the WWBump macro.


>
>Line 2 get the SDRAM base address for the xfer reg to copy packet data 
>into.
>
>Line 3 get the packet offset currently located in buffer (rfifo? SDRAM?), 
>and i wonder how, by this command, the rfifo (SDRAM?) will know which is 
>the correct current packet offset to return, amongst so many packets 
>resided in rfifo (SDRAM?).
>

The dl_buffer_handle is the buffer handle for one particular packet, and it 
is set some where before the above code, probably by Ingress. You will have 
to look at the dispatch loop and follow the macros to understand. The SDRAM 
doesn't return anything, the offset is calculated by your code that puts the 
data in the SDRAM in the first place. Look at the code for dispatch loop 
macros for a better idea.


>Assume IP header = 20 bytes, dpoff = 36 bytes.
>Line 4 & 5 calculate dpoff and convert to quadword. In this context, SDRAM 
>should read from 32 - 39 bytes. But, how does the SDRAM knows to read from 
>32 bytes, instead of 36 bytes?? Is there an internal mechanism to convert??
>

Line 5 converts the boff to a quadword, by dividing it by 8 (>>3). So a 
value of 36 will turn into 4 after line 5. The 4th quadword starts with byte 
32. Again, it is your code that is doing the conversion, and no internal 
mechanism.


>Line 6, this line, make me confuse, i assume, this line actually read 
>packet data from SDRAM into transfer register, where the packet data 
>offset, is at base+boff. So, the previous assumption --> data is in rfifo 
>is wrong. Then, which part of the code in WWBump, where microengine 
>instructs IX-Bus to transfer packet into SDRAM??
>

If WWBump doesn't have the code, I guess there is some code (probably 
EthernetIngress) that does the stuff. Look at the dispatch loop to see what 
is called before WWBump.

That's what I can assume, someone who has the book will be able to shed more 
light on the code.

--
Shyamal Pandya

Addr:
920 S Terrace Rd #102
Tempe AZ 85281
Phone:
1-480-966-1982

_________________________________________________________________
Share your photos without swamping your Inbox.  Get Hotmail Extra Storage 
today! http://join.msn.com/?PAGE=features/es