From: MIke W. <we...@cs...> - 2010-08-05 15:03:34
|
The full 8 byte trailer is ALWAYS located at offset +40 from start of last cell. Hence length is always located at offset +42 from start of last cell (as it was in your examples). Mike mahendra varman wrote: > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length > count of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the > last cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some > register how to find the trailer in the entire content of the last cell ? > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm... > <mailto:wri...@gm...>> wrote: > > And if that kind of register is not there then system should have > max possible length of buffer (perhaps mtu sized) and then as we > get cells we put there and when we received last cell of all5 > (based on PTI field) we remove the padding and send only user data > to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall > <we...@cs... <mailto:we...@cs...>> wrote: > > I'm not 100% sure what you are asking here. Some NICs (that > do SAR) > have registers that the driver can read to determine > application payload > length. At minimum you MUST be able (somehow) to know how many > cell's comprise the AAL5 PDU. But once you can do that the > rest is > trivial.. The CS trailer is always "right" justified in the > LAST cell of the > PDU. > In your second example, 80 byte payload requires two cells. > Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU > at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be > located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > > Hi > In the ATM driver during reception, I have a doubt in > finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the dump > of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 > 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 > as length indicator. > > > 2. If the user send me 80 bytes of data, below is the dump > of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e > 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 > bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 > as length indicator > > But, In realtime I do not know how many bytes the user > will send to me. > The padding bytes and the trailer area in the last buffer > differs > depending on the number of received bytes. I need to get > the length > indicator field through some logic irrespective of the > number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm > for a share > of $1 Million in cash or HP Products. Visit us here for > more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > ------------------------------------------------------------------------ > > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > |