From owner-freebsd-atm Tue Jul 30 09:29:42 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA14681 for atm-outgoing; Tue, 30 Jul 1996 09:29:42 -0700 (PDT) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA14671 for ; Tue, 30 Jul 1996 09:29:40 -0700 (PDT) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.1/8.7.1) id LAA22938 for freebsd-atm@freebsd.org; Tue, 30 Jul 1996 11:29:34 -0500 (CDT) Date: Tue, 30 Jul 1996 11:29:34 -0500 (CDT) From: Mark Tinguely Message-Id: <199607301629.LAA22938@plains.nodak.edu> To: freebsd-atm@freebsd.org Subject: IDT driver Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I finally figured out all the of the little details of the IDT NICStAR (the transmission schedule table modification didn't make sense at first, but I finally got a clue.) I am going on vacation from Thursday through Tuesday and hopefully my cards should arrive here next week. I plan on writing code starting next week, with or without the cards. Since, I don't want to reinvent the wheel, has anyone made any progress on a IDT NICStAR driver? Since the NICStAR uses host memory for recieve and transmition buffers, I plan to allocate a huge chunk (in the 1+ MB neighborhood) of memory for buffers. I would allocate this amount of memory for bufferes for ATM enviroments that assemble and transfer full PDUs into host memory also. it would take 1 MB to fill the "large" recieve buffer queue using 2K buffers. this is not saying I would need to fill the recieve buffer queue, and at this time I am not saying 2K buffers are the buffer size I would use; I am simply using the numbers to show that it will take a lot of host memory to keep ATM running smoothly. The other thing that will require more buffers is the fact that once a buffer is on the recieve queue, it is dedicated to the recieve queue until the NICStAR hands it back filled with a PDU. So we can throw transmission buffers on the recieve queue at times of heavy input, but we can't grab them back on times of heavy transmission. To get the most use of the "small" buffer, I would vote for using the largest possible "small" buffer (5 cells). The purpose of the "small" buffers is capture the relatively short lengthed Legacy LAN data in the "small" buffer and not have to use the "large" buffer. To capture TCP/IP headers plus small payloads, we are looking at 4 cells worth of information. --mark.