[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New version of ngATM
>
> 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@xxxxxxxxxxxxxxxxxxxx:/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@xxxxxxxxxxx
with "unsubscribe freebsd-atm" in the body of the message
