From owner-freebsd-atm Mon Aug 19 10:44:42 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA18461 for atm-outgoing; Mon, 19 Aug 1996 10:44: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 KAA18448 for ; Mon, 19 Aug 1996 10:44:40 -0700 (PDT) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.5/8.7.3) id MAA12482 for freebsd-atm@freebsd.org; Mon, 19 Aug 1996 12:44:26 -0500 (CDT) Date: Mon, 19 Aug 1996 12:44:26 -0500 (CDT) From: Mark Tinguely Message-Id: <199608191744.MAA12482@plains.nodak.edu> To: freebsd-atm@freebsd.org Subject: IDT 77201 buffer size opinions wanted Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have the register 10 (pages 96-99) commands except read/write utilities working. The read/write utilities are something I see as important yet. The Errata for the revision D board says we can up the small buffer size to 2K bytes or if you think you can get all the packets into a single large buffer, the small buffer can be bypassed (but if a larger cell does not fit into *one* large buffer, a CRC error will result). I have eliminated the large-only buffer option as too expensive because all buffers would have to be 16K to handle the IETF's MTU. The small buffer size can be 48, 96, 240, or 2048 bytes. The large buffer size can be 2K, 4K, 8K or 16K but once set it cannot change. on packet recption, buffers are delivered to the driver in a group and the driver would have to force these into mbufs (I still hope that the external mbuf will let me use these without a seperate copy, if it can we can use the same logic for DMA packet from cards with onboard RAM for packet contruction). We have the option of using the 5 cell small buffer and a 2K+ large buffer. This uses the logic that majority of IP traffic is small and small buffers will handle most of the traffic with little buffer waste. Another option could be using 2K large and small buffers taken from a common allocation pool (the driver will have to keep track of where the buffers are queued). There is a danger of one queue getting too many buffers because the can't take them off a queue until the hardware returns the buffer with a data packet. I am afraid we will have lots of wasted space just like IP wastes buffer space. but it should simplify buffer management downstream. Talking myself from favoring option one to option two, I will code an option 3 that small and large are seperate buffer pools, both 2K in size (and a ifdef could change the size) but the downstream will have to handle to potential that large and small buffers are different sizes. This worse case of each. If anyone has strong feelings about this, *please comment*. --mark. From owner-freebsd-atm Mon Aug 19 12:46:10 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA06381 for atm-outgoing; Mon, 19 Aug 1996 12:46:10 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA06370 for ; Mon, 19 Aug 1996 12:46:07 -0700 (PDT) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA01847; Mon, 19 Aug 1996 15:38:07 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA26055; Mon, 19 Aug 1996 15:38:04 -0400 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id PAA04105; Mon, 19 Aug 1996 15:42:33 GMT Message-Id: <199608191542.PAA04105@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Mark Tinguely Cc: freebsd-atm@freebsd.org Subject: Re: IDT 77201 buffer size opinions wanted In-Reply-To: Your message of "Mon, 19 Aug 1996 12:44:26 EST." <199608191744.MAA12482@plains.nodak.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 1996 15:42:33 +0000 From: Matt Thomas Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FWIW, this is what I'm doing for the ATM driver I'm writing (for a Digital designed ATM card). The card uses 3 buffer sizes, the smallest is for a single cell. The middle is programmable and will set to 256 bytes initially (I may make it larger based on experience). The large size will be 4KB (ie. one page). I plan on using wrapping the buffers in external mbufs. This will require changing the current method of reference counting to the much flexible method used in OSF/1 (the m_ext structure contains a circular queue which contains all external mbufs that reference this data). The driver is merely a data pusher. It has some calls for dealing with setup of VCs but they are very basic. I plan on something like: int (*vc_create)(unsigned vpi, unsigned vci, enum type, vc_token_t *vc_p); int (*vc_set_attr)(vc_token_t vc, vc_attr_t, ...); int (*vc_aal5_transmit)(vc_token_t vc, void *kva, size_t *len, int flags); int (*vc_destroy)(vc_token_t vc); Above the driver will a set of adapter-independent code which handle the CLIP, LANE, and raw character device interface to an adapter, and eventually ATM signalling code. Since the CLIP/LANE drivers really correspond to the ifnet layers, I've created another list for the ATM devices. Initially, I just plan on doing the data movement part and the character cell interface (ie. the minimal amount to device "working"). After that, who knows? Probably CLIP support. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message