Re: R: [ATMSAR] Request for review - update #1
On Sunday 04 September 2005 19:36, Giampaolo Tomassoni wrote: [snip] > > This may be true for AAL5 support, which is the way by which data is > actually transferred between ADSL DSLAMs and CPE equipment. > > This may not be generally true, however: most providers are already > delivering internet+voice solutions over ADSL channels (here in Italy, in > example, Telecom offers Alice Mia, which is an ADSL line with internet > access and VoIP for added voice capabilities). Albeit the voice part of > these solutions are actually based on VoIP technology, it is not the best > way to do this. In the future, I believe we will easily see internet + > voice sols based over AAL5 + AAL2/3, or even multi voice channels over > AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX > connection). > > When (and if) that will happen, we will probabily need a kernel-based > solution since cell timing and QoS is a much stricter requirement with > non-AAL5 encodings, such that it is easier to attain from inside the kernel > than from userland. > > So, I'm not that shure all the ATM code is to be stripped out of the > kernel. Maybe it can be done with the PPPoATM network interface. But > probably it can't be done with the ATM core and the ATM SAR code. Wherever > the latter will be in ATMUSB, in ATMSAR or in a device driver. The above is a decent technical justification for why the code is generally required; it's set my mind at rest, I thought maybe this was only for the speedtouch modem crew. I was aware of ATM's ability to interleave data and "digital voice" services; ATM is widely deployed across Europe in preparation for "pure digital" consumer telephony.. My primary concern with the ATM code is that it's not (yet) an often used part of the kernel; there are a number of viable applications out there, but most can happily use linux-atm and/or pppd. I can see VoIP clients doing the same. However, for embedded or non-pure-client purposes, there's a reason for an in-kernel implementation. I don't know enough about the applications of the "ATM stack" versus using a userspace library, so I think as long as the patch is cleaned up and can be reused, it's okay to put in the kernel. > > The PPPoATM module is a network interface. It stays on the other side of > the ATM world: [netif] <-> [PPPoATM] <-> [atmif] <-> [ATM] <-> [ATMSAR] <-> > [device driver]. I'm not a PPPoATM expert, but it may probably be possible > to have all the PPPoATM code in userland. But the [ATM] <-> [ATMSAR] <-> > [device driver] chain is probably too close to hardware to gain any benefit > by "userlanding" it. > I agree, if there are users beyond the speedtouch modem, it may make sense to have this code in the kernel. Thanks for fielding my questions. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
R: [ATMSAR] Request for review - update #1
> -Messaggio originale- > Da: Alistair John Strachan [mailto:[EMAIL PROTECTED] > Inviato: domenica 4 settembre 2005 18.21 > > ...omissis... > > Just out of curiosity, is there ANY reason why this has to be done in the > kernel? The PPPoATM module for pppd implements (via linux-atm) a > completely > userspace ATM decoder.. if anything, now redundant ATM stack code > should be > REMOVED from Linux! This may be true for AAL5 support, which is the way by which data is actually transferred between ADSL DSLAMs and CPE equipment. This may not be generally true, however: most providers are already delivering internet+voice solutions over ADSL channels (here in Italy, in example, Telecom offers Alice Mia, which is an ADSL line with internet access and VoIP for added voice capabilities). Albeit the voice part of these solutions are actually based on VoIP technology, it is not the best way to do this. In the future, I believe we will easily see internet + voice sols based over AAL5 + AAL2/3, or even multi voice channels over AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX connection). When (and if) that will happen, we will probabily need a kernel-based solution since cell timing and QoS is a much stricter requirement with non-AAL5 encodings, such that it is easier to attain from inside the kernel than from userland. So, I'm not that shure all the ATM code is to be stripped out of the kernel. Maybe it can be done with the PPPoATM network interface. But probably it can't be done with the ATM core and the ATM SAR code. Wherever the latter will be in ATMUSB, in ATMSAR or in a device driver. The PPPoATM module is a network interface. It stays on the other side of the ATM world: [netif] <-> [PPPoATM] <-> [atmif] <-> [ATM] <-> [ATMSAR] <-> [device driver]. I'm not a PPPoATM expert, but it may probably be possible to have all the PPPoATM code in userland. But the [ATM] <-> [ATMSAR] <-> [device driver] chain is probably too close to hardware to gain any benefit by "userlanding" it. > > ...omissis... > > > -- > Cheers, > Alistair. Cheers, giampaolo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
R: [ATMSAR] Request for review - update #1
-Messaggio originale- Da: Alistair John Strachan [mailto:[EMAIL PROTECTED] Inviato: domenica 4 settembre 2005 18.21 ...omissis... Just out of curiosity, is there ANY reason why this has to be done in the kernel? The PPPoATM module for pppd implements (via linux-atm) a completely userspace ATM decoder.. if anything, now redundant ATM stack code should be REMOVED from Linux! This may be true for AAL5 support, which is the way by which data is actually transferred between ADSL DSLAMs and CPE equipment. This may not be generally true, however: most providers are already delivering internet+voice solutions over ADSL channels (here in Italy, in example, Telecom offers Alice Mia, which is an ADSL line with internet access and VoIP for added voice capabilities). Albeit the voice part of these solutions are actually based on VoIP technology, it is not the best way to do this. In the future, I believe we will easily see internet + voice sols based over AAL5 + AAL2/3, or even multi voice channels over AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX connection). When (and if) that will happen, we will probabily need a kernel-based solution since cell timing and QoS is a much stricter requirement with non-AAL5 encodings, such that it is easier to attain from inside the kernel than from userland. So, I'm not that shure all the ATM code is to be stripped out of the kernel. Maybe it can be done with the PPPoATM network interface. But probably it can't be done with the ATM core and the ATM SAR code. Wherever the latter will be in ATMUSB, in ATMSAR or in a device driver. The PPPoATM module is a network interface. It stays on the other side of the ATM world: [netif] - [PPPoATM] - [atmif] - [ATM] - [ATMSAR] - [device driver]. I'm not a PPPoATM expert, but it may probably be possible to have all the PPPoATM code in userland. But the [ATM] - [ATMSAR] - [device driver] chain is probably too close to hardware to gain any benefit by userlanding it. ...omissis... -- Cheers, Alistair. Cheers, giampaolo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: R: [ATMSAR] Request for review - update #1
On Sunday 04 September 2005 19:36, Giampaolo Tomassoni wrote: [snip] This may be true for AAL5 support, which is the way by which data is actually transferred between ADSL DSLAMs and CPE equipment. This may not be generally true, however: most providers are already delivering internet+voice solutions over ADSL channels (here in Italy, in example, Telecom offers Alice Mia, which is an ADSL line with internet access and VoIP for added voice capabilities). Albeit the voice part of these solutions are actually based on VoIP technology, it is not the best way to do this. In the future, I believe we will easily see internet + voice sols based over AAL5 + AAL2/3, or even multi voice channels over AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX connection). When (and if) that will happen, we will probabily need a kernel-based solution since cell timing and QoS is a much stricter requirement with non-AAL5 encodings, such that it is easier to attain from inside the kernel than from userland. So, I'm not that shure all the ATM code is to be stripped out of the kernel. Maybe it can be done with the PPPoATM network interface. But probably it can't be done with the ATM core and the ATM SAR code. Wherever the latter will be in ATMUSB, in ATMSAR or in a device driver. The above is a decent technical justification for why the code is generally required; it's set my mind at rest, I thought maybe this was only for the speedtouch modem crew. I was aware of ATM's ability to interleave data and digital voice services; ATM is widely deployed across Europe in preparation for pure digital consumer telephony.. My primary concern with the ATM code is that it's not (yet) an often used part of the kernel; there are a number of viable applications out there, but most can happily use linux-atm and/or pppd. I can see VoIP clients doing the same. However, for embedded or non-pure-client purposes, there's a reason for an in-kernel implementation. I don't know enough about the applications of the ATM stack versus using a userspace library, so I think as long as the patch is cleaned up and can be reused, it's okay to put in the kernel. The PPPoATM module is a network interface. It stays on the other side of the ATM world: [netif] - [PPPoATM] - [atmif] - [ATM] - [ATMSAR] - [device driver]. I'm not a PPPoATM expert, but it may probably be possible to have all the PPPoATM code in userland. But the [ATM] - [ATMSAR] - [device driver] chain is probably too close to hardware to gain any benefit by userlanding it. I agree, if there are users beyond the speedtouch modem, it may make sense to have this code in the kernel. Thanks for fielding my questions. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
