Re: [ixp1200] WWBump Code in 'Network System Design'
When SDRAM is accessed from microengines the address must be quadword (8-byte) aligned. Consider the following two cases: Case I: (minimum IP header length) Assume IP HLEN = 20, dpoff = 14 + 20 + 2 = 36 bytes That is destination port offset will be at byte ofset 36 & 37. The packet data will have to be accessed from byte offset 32 because of the 8-byte alignment requirement. So the first longword contains bytes 32, 33, 34 and 35. The second longword begins with the destination port. also 36 AND 0x7 == 4 Case II: (IP header length 24 bytes) Assume IP HLEN = 24, dpoff = 14 + 24 + 2 = 40 bytes That is destination port offset will be at byte offset 40 & 41. Here the packet data can be accessed from byte 40, so that the first longword contains the destination port. Also 40 AND 0x7 == 0 Hope this clears the doubt. -- Shyamal Pandya Arizona State University Addr: 920 S Terrace Rd #102 Tempe AZ 85281 Phone: 1-480-966-1982
From: Lim Boon Ping
Reply-To: ixp1200@CS.Princeton.EDU To: ixp1200@CS.Princeton.EDU Subject: [ixp1200] WWBump Code in 'Network System Design' Date: Tue, 30 Sep 2003 23:37:34 -0700 (PDT) Hi all,
This is a question regarding WWBump example code in 'Network System Design, using network processors', from Prof. Douglas Comer.
Trace through the code in WWBump.uc, i have some questions on the section regarding extracting destination port from SDRAM transfer register. I might have misunderstood the overall concept behind these codes, and hope if someone could point out.
Thanks in advance.
....
/* 'dpoff' contains the offset for destination port in TCP packet,*/ /* that is 14 bytes Ethernet header + n bytes IP header + 2 */ /* bytes source port, where n has been calculated earlier. */
/* Use lower three bits of the byte offset to determine which */ /* byte the destination port will be in. If value >= 4, dest. */ /* port is in the 2nd longword; otherwise it's in the first. */ alu[ dpoff, dpoff, AND, 0x7 ] ; Get lowest three bits alu[ --, dpoff, -, 4] ; Test and conditional br>=0[SecondWord#] ; branch if value >=4
FirstWord#: /* Load upper two bytes of register $$hdr0 */ ld_field_w_clr[dport, 0011, $$hdr0, >>16] ; Shift before mask br[GotDstPort#] ; Check port number
SecondWord#: /* Load lower two bytes of register $$hdr1 */ ld_field_w_clr[dport, 0011, $$hdr1, >>16] ; Shift before mask
.....
May i know why the author uses lower 3 bits of the byte offset to determine byte the destination port will be in?
Isnt' dpoff has pointed to the offset of destination port, extracting 8 bytes from the offset onwards will always start from destination port until the first 2 bytes of ACK number, (means it will always be in $$hdr0) ?
Then why must the code check for condition as it will never branch to SecondWord#?
If it will branch to SecondWord#, under what condition?
I have done some calculation, please kindly indicate if i have misunderstood the concept.
Case I: (minimum IP header length)
Assume IP HLEN = 20, dpoff = 14 + 20 + 2 = 36 bytes That is destination port offset will be at 37 & 38 bytes of the packet.
36 bytes -> 288 bits -> 100100000 100100000 & 000000111 = 000000000 /* dpoff AND 0x7 */ result: branch to FirstWord#
Case II: (40 bytes IP header length)
Assume IP HLEN = 40, dpoff = 14 + 40 + 2 = 56 bytes That is destination port offset will be at 57 & 58 bytes of the packet.
56 bytes -> 448 bits -> 111000000 111000000 & 000000111 = 000000000 /* dpoff AND 0x7 */ result: branch to FirstWord#
Case III: (60 bytes IP header length)
Assume IP HLEN = 60, dpoff = 14 + 60 + 2 = 76 bytes That is destination port offset will be at 77 & 78 bytes of the packet.
76 bytes -> 608 bits -> 1001100000 1001100000 & 000000111 = 000000000 /* dpoff AND 0x7 */ result: branch to FirstWord#
Best regards, Lim Boon Ping --------------------------------------- Post-Graduate Student Multimedia University Cyberjaya, Malaysia
--------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
_________________________________________________________________ Add MSN 8 Internet Software to your existing Internet access and enjoy patented spam protection and more. Sign up now! http://join.msn.com/?page=dept/byoa
Hi all, Thanks Shyamal! I've visualize and understood the problem. But i think the previous confusion is due to my misunderstanding on the below line of code, 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? ] 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?). 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 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?? Best regards, Lim Boon Ping --------------------------------------- Post-Graduate Student Multimedia University Cyberjaya, Malaysia --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
participants (2)
-
Lim Boon Ping
-
Shyamal Pandya