Date: Mon, 10 Feb 2003 23:27:28 +0100 From: Vincent Jardin <vjardin@wanadoo.fr> To: Harti Brandt <brandt@fokus.fraunhofer.de> Cc: atm@freebsd.org Subject: Re: New version of ngATM Message-ID: <3E26DA7000E6DF75@mel-rta8.wanadoo.fr> (added by postmaster@wanadoo.fr) In-Reply-To: <20030210105145.K33486@beagle.fokus.gmd.de> References: <20030207174401.H1348@beagle.fokus.gmd.de> <3E26CE5400E3E458@mel-rta7.wanadoo.fr> <20030210105145.K33486@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The HARP drivers are i386 only. Conerting to busdma is a major effort, > especially if they must work on 64-bit platforms, which are now tier-1. However the HARP drivers and stack have been working on Sun. http://www.msci.magic.net/harp/ SunOS 4.1.x on Sun SPARC (sun4c, sun4m) workstations Isn't enough ? I agree about the 64-bit platforms, I do not have any. I could not help about it ;-(. Nevertheless I am not sure that lot of thinks will need to be fixed. Only mainly the IDT drivers need some fixed ;-) Another issue with HARP is to get it ready with the new SMP architecture ;-( Due to the Netgraph architecture, ngATM should already support SMP ;-)) > > VJ>The idea of ngATM sounds nice : it provides a good new driver in order > to VJ>support the HFA 155 board. However, HARP provides already most of the > ATM VJ>features. However the HARP stack lacks of : > VJ> - drivers: > VJ> + up to now there is no ADSL driver ;-( > VJ> + there is no OC12 driver > > The HE driver should also support the HE622. At least I have the code > there. I think we have such boards here, if there is serious interest, I > will try it. Nice ;-)) > > VJ> - features: > VJ> + soft SAR that could be required by many ADSL drivers. > > That is actually easy. I have written AAL5 SAR code more often then I > wish I had. I know, however I was thinking of the HARP API and the SAP (Service Access Point) of the SAR layer. Moreover it should be enough efficient in order to minimize the copy of memory. > > VJ> + OAM F4 and F5 support > > Well, the main problem with this is to get a nice interface between the > components. The actual programming should be not to hard (provided the > cards support this). It is supported by the Prosum's driver: see proatm_process_rcqe() It might help. > VJ>Could you describe the differences between ngATM and HARP ? > > From the design perspective: I prefer to have the components of the ATM > stack more independent of each other. This makes ngATM much lesser > monolithic than HARP. You can, for example, use the ng_sscop node as a > general transport protocol (it performs nice over long delay links). It is > very easy to add things or modify them. I agree that Netgraph helps to define a clean API of the components. However, HARP has its own one too that is defined in atm_stack.h. Moreover like ngATM, HARP has been designed in order to support dynamic load and unload ;-) I have been surprised to see this dynamic support into a so old code ;-) > > From the technical point of view: drivers for PCA200 and HE155/622 (others > in the pipe). LAN emulation v2 and a ATM-Forum compatible ATM API. Full > remote configuration. Great about the new drivers. Would they support both HARP and ngATM too ? What do you mean by full remote configuration ? > > VJ>Moreover in order to emulate an ATM link, I think that Netgraph could > VJ>be used too to provide a virtual PIF. For example in order to emulate > VJ>an ATM link without any ATM board, a ng_HARPDEVICE node could provide > VJ>on one side a Netgraph hook and on the other side a HARP PIF (Physical > VJ>Interface). The Netgraph hook could be used over a UDP socket that > VJ>emulates the physical ATM link. > > That's actually a nice idea. I see if I can do something like this. > Remembers me of some ATM over ethernet stuff from Bell Labs. > How would you multiplex the VCs on UDP/TCP? A simple PDU prefix that provides only the VPi, VCi, PTI, and CLP. Then this node could be used upon ng_ksocket. It means that it could be used whatever upon UDP or TCP ;-) ng_bridge, ng_pppoe or ng_l2tp are good example of the multiplexing of many lower session. PTI is required in order to emulate OAM F5. > > VJ>Then what are the differences between your PCA200 driver and the HARP's > VJ>one ? > > # uname -a > FreeBSD catssrv.fokus.gmd.de 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Tue Jan > 28 11:49:32 CET 2003 > hbb@catssrv.fokus.gmd.de:/opt/obj/usr/src/sys/CATSSRV sparc64 # ifconfig > hme0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet 192.168.229.23 netmask 0xffffff00 broadcast 192.168.229.255 > ether 08:00:20:b5:d3:15 > media: Ethernet autoselect (100baseTX) > status: active > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > hatm0: flags=841<UP,RUNNING,SIMPLEX> mtu 9180 > media: ATM UTP/155MBit > status: active > fatm0: flags=841<UP,RUNNING,SIMPLEX> mtu 9180 > media: ATM UTP/155MBit > status: active > lane0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1516 > inet 192.168.173.7 netmask 0xffffff00 broadcast 192.168.173.255 > ether 00:a0:3e:23:02:00 It is a good example of the differences ;-)) Moreover on a Sparc64 ;-D Did you try to support the BPF with the atm physical interfaces ? See the DLT_SUNATM into the current version of tcpdump (www.tcpdump.org). Or http://www.ethereal.com/lists/ethereal-users/200211/msg00047.html for a description of the BPF header of DLT_SUNATM Thanks for all, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E26DA7000E6DF75>