From: Chas W. (CONTRACTOR) <ch...@cm...> - 2010-08-06 04:56:32
|
ask mike said, for aal5 the last cell in the pdu (which is indicated via the pti bits as i recall) will contain the complete aal5 trailer -- padding the pdu so that the trailer will appear in the last 8 bytes of the last cell. this website has some diagrams of these layouts: http://www.protocols.com/pbook/atm.htm generally, the atm hardware will deliver either a full pdu to you or fragments of the pdu as its arrives. if you get fragments you need to chain them together until you have a completely assembled pdu. this can be tricky since you dont know the size of the pdu ahead of time since the information is in the trailer. either keep a linked list of these fragments or guess at the size, alloc a skb, and grow (realloc) the skb as necessary to keep appending the data. the assembled pdu should be some multiple of 48. once you have the full pdu, you will find the trailer at the end, so determine the aal5 length, truncate the skb to this length and push the skb into the atm/network layer. you can take a look at the atm he driver, look for the AAL5_LEN() macro. dont forget that this length is big endian -- dont forget to convert to cpu endian before using it. In message <AAN...@ma...>,mahendra varman writes: >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...> 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...>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 >>>> >>>> >>>> >>>> >>> >> > >--000e0cd3317ee36175048d1494c9 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><br>I could able to receive all the cells upto last cell.<br>I do not have = >a register in the ATM controller indicating the length count of the receive= >d<br>bytes ( the datasheet claims the length count is done internally and u= >pdated in the last cell)<br> ><br>I need to remove padding and send only user data to upper layer.<br><br= >>I have only the last cell buffer address and entire content of the last ce= >ll including padding <br>and trailer.<br><br>My doubt is Since I do not hav= >e the length indicator through some register how to find the trailer in the= > entire content of the last cell ?<br> ><br><br><br><br><br><div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 8:06 = >PM, Ashish <span dir=3D"ltr"><<a href=3D"mailto:writetoashishgupta@gmail= >.com">wri...@gm...</a>></span> wrote:<br><blockquote cla= >ss=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px sol= >id rgb(204, 204, 204); padding-left: 1ex;"> >And if that kind of register is not there then system should have max possi= >ble length of buffer (perhaps mtu sized) and then as we get cells we put th= >ere and when we received last cell of all5 (based on PTI field) we remove t= >he padding and send only user data to upper layer.<br> ><font color=3D"#888888"> ><br>--Ashish</font><div><div></div><div class=3D"h5"><br><br><div class=3D"= >gmail_quote">On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <span dir=3D"ltr"= >><<a href=3D"mailto:we...@cs..." target=3D"_blank">westall@cs= >.clemson.edu</a>></span> wrote:<br> ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= >r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> >I'm not 100% sure what you are asking here. =A0 Some NICs (that do SAR)= ><br> >have registers that the driver can read to determine application payload<br= >> >length. =A0 At minimum you MUST be able (somehow) to know how many<br> >cell's comprise the AAL5 PDU. =A0 But once you can do that the rest is<= >br> >trivial.. =A0The CS trailer is always "right" justified in the LA= >ST cell of the<br> >PDU. =A0<br> >In your second example, =A080 byte payload requires two cells. =A0Two cells= ><br> >have payload capacity 96. =A0 Thus CRC is at offset 92 with UU at offset 88= >,<br> >CPI at 89 and len at offset 90. <br> >Stated another way the 2 byte length field will always be located 6 bytes<b= >r> >before the end of the last 48 byte cell. =A0 =A0<br> >mahendra varman wrote:<br> ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= >r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><= >div> >Hi<br> >In the ATM driver during reception, I have a doubt in finding the<br> >length of the received bytes.<br> ><br> >1. If the user send me 40 bytes of data, below is the dump of the<br> >buffer with trailer<br> ><br> >=A0size: 56 getrsmbuffer =3D cf888000<br> >---------------------------------------------------------------------------= >----------------------------------<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 = >0x69<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 = >0x69<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x2= >1<br> >0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f<br> ><br> >0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 =3D trailer with 0x28 as length indica= >tor.<br> ><br> ><br> >2. If the user send me 80 bytes of data, below is the dump of the LAST<br> >buffer with trailer<br> ><br> >=A0size: 56 getrsmbuffer =3D cf878048<br> >=A0------------------------------------------------------------------------= >---------------------------------------------------<br> ><br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 = >0x69<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0<br> >0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb<br= >> >0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0<br> ><br> >0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 =A0 =A0 =A0 =A0 =3D padding data(8 bytes) a= >fter data 0x69<br> >0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 =3D =A0trailer with 0x50 as length ind= >icator<br> ><br> >But, In realtime I do not know how many bytes the user will send to me.<br> >The padding bytes and the trailer area in the last buffer differs<br> >depending on the number of received bytes. I need to get the length<br> >indicator field through some logic irrespective of the number of<br> >received bytes.<br> ><br> >Can you please help me on the above ?<br> ><br> >Mahendra<br> ><br></div></div> >---------------------------------------------------------------------------= >---<br> >The Palm PDK Hot Apps Program offers developers who use the<br> >Plug-In Development Kit to bring their C/C++ apps to Palm for a share<br> >of $1 Million in cash or HP Products. Visit us here for more details:<br> ><a href=3D"http://p.sf.net/sfu/dev2dev-palm" target=3D"_blank">http://p.sf.= >net/sfu/dev2dev-palm</a><br> >_______________________________________________<br> >Linux-atm-general mailing list<br> ><a href=3D"mailto:Lin...@li..." target=3D"_blank= >">Lin...@li...</a><br> ><a href=3D"https://lists.sourceforge.net/lists/listinfo/linux-atm-general" = >target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/linux-atm-ge= >neral</a><br> ><br> ><br> > =A0<br> ></blockquote> ></blockquote></div><br> ></div></div></blockquote></div><br> > >--000e0cd3317ee36175048d1494c9-- > |