Date: Tue, 11 Feb 2003 10:11:47 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Vincent Jardin <vjardin@wanadoo.fr> Cc: atm@freebsd.org Subject: Re: New version of ngATM Message-ID: <20030211095938.I3109@beagle.fokus.gmd.de> In-Reply-To: <3E26DA7000E6DF75@mel-rta8.wanadoo.fr> (added by postmaster@wanadoo.fr) References: <20030207174401.H1348@beagle.fokus.gmd.de> <3E26CE5400E3E458@mel-rta7.wanadoo.fr> <20030210105145.K33486@beagle.fokus.gmd.de> <3E26DA7000E6DF75@mel-rta8.wanadoo.fr> (added by postmaster@wanadoo.fr)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Feb 2003, Vincent Jardin wrote: VJ>> VJ>> The HARP drivers are i386 only. Conerting to busdma is a major effort, VJ>> especially if they must work on 64-bit platforms, which are now tier-1. VJ> VJ>However the HARP drivers and stack have been working on Sun. VJ> http://www.msci.magic.net/harp/ VJ> SunOS 4.1.x on Sun SPARC (sun4c, sun4m) workstations VJ>Isn't enough ? VJ> VJ>I agree about the 64-bit platforms, I do not have any. I could not help about VJ>it ;-(. Nevertheless I am not sure that lot of thinks will need to be fixed. VJ>Only mainly the IDT drivers need some fixed ;-) A doubt, because what I have seen in the stack so far is a very loose mixing of longs, ints and pointers. They all have the same size on both sparc32 (SunOS and sparc), but are different on all 64-bit platforms. Large parts of the hfa driver must be rewritten for 64-bit. This is because how the card handles buffers. There is no point in doing this when we already have if_fatm/if_harp. VJ>> VJ> + OAM F4 and F5 support VJ>> VJ>> Well, the main problem with this is to get a nice interface between the VJ>> components. The actual programming should be not to hard (provided the VJ>> cards support this). VJ> VJ>It is supported by the Prosum's driver: see proatm_process_rcqe() It might VJ>help. Sure. Having those cells in the driver is no problem for most cards. But what to do with them next. The problem is to specify an API what to do with those cells once you have them. VJ>> VJ>Could you describe the differences between ngATM and HARP ? VJ>> VJ>> From the design perspective: I prefer to have the components of the ATM VJ>> stack more independent of each other. This makes ngATM much lesser VJ>> monolithic than HARP. You can, for example, use the ng_sscop node as a VJ>> general transport protocol (it performs nice over long delay links). It is VJ>> very easy to add things or modify them. VJ> VJ>I agree that Netgraph helps to define a clean API of the components. VJ>However, HARP has its own one too that is defined in atm_stack.h. VJ>Moreover like ngATM, HARP has been designed in order to support dynamic VJ>load and unload ;-) I have been surprised to see this dynamic support VJ>into a so old code ;-) Actually it doesn't work very well. Unloading the if_harp driver leads to lockups, panics and other funny things within a couple of minutes. The problem seems to be that the interface unregister function does nothing about any open vccs (just a guess). VJ>> From the technical point of view: drivers for PCA200 and HE155/622 (others VJ>> in the pipe). LAN emulation v2 and a ATM-Forum compatible ATM API. Full VJ>> remote configuration. VJ> VJ>Great about the new drivers. Would they support both HARP and ngATM too ? VJ>What do you mean by full remote configuration ? As I said in an earlier mail they support HARP, ngATM and NATM. The entire ngATM configuration is done via an SNMP daemon (which does also ILMI). So you are able to do everything remote. You can configure and monitor almost all ATM related stuff via SNMP. VJ>A simple PDU prefix that provides only the VPi, VCi, PTI, and CLP. Then this VJ>node could be used upon ng_ksocket. It means that it could be used whatever VJ>upon UDP or TCP ;-) ng_bridge, ng_pppoe or ng_l2tp are good example of the VJ>multiplexing of many lower session. VJ>PTI is required in order to emulate OAM F5. Ok. VJ>It is a good example of the differences ;-)) Moreover on a Sparc64 ;-D VJ> VJ>Did you try to support the BPF with the atm physical interfaces ? See the VJ>DLT_SUNATM into the current version of tcpdump (www.tcpdump.org). VJ>Or VJ> http://www.ethereal.com/lists/ethereal-users/200211/msg00047.html VJ>for a description of the BPF header of DLT_SUNATM At the moment I have restricted BPF to LLC/SNAP non-ngATM VCIs (that means NATM and HARP). This is just a matter of removing an if(). Nice to see, that ATM makes it into tcpdump. We were trying to convince the tcpdump people about this since around 94 :-( harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org 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?20030211095938.I3109>