From: Ashish <wri...@gm...> - 2010-08-05 14:36:20
|
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...> 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... >> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >> >> >> >> > |