From owner-freebsd-hackers Fri Sep 4 17:49:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08076 for freebsd-hackers-outgoing; Fri, 4 Sep 1998 17:49:26 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08071 for ; Fri, 4 Sep 1998 17:49:25 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id AAA02105; Sat, 5 Sep 1998 00:41:31 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199809050741.AAA02105@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bill Paul cc: hackers@FreeBSD.ORG Subject: Re: Questions for networking gurus In-reply-to: Your message of "Fri, 04 Sep 1998 19:26:53 EDT." <199809042326.TAA13218@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Sep 1998 00:41:31 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [... describes ethernet hardware designed by idiots, and possible workaround ...] > 2) What's the longtest time than an mbuf chain with received packet data > will survive inside the kernel? The driver has to allocate enough > memory so that it can continue handling data from the chip while > waiting for previous buffers to be freed by the protocols, but if > an mbuf can get hung up inside the protocols for a very long time > (or worse, be locked indefinitely), then the buffer allocation > would be ridiculously large. This would outweight the benefit of > avoiding copies. I would have to worry about an mbuf that gets routed into the outbound queue for a slow (eg. ppp) interface. I'd expect that such a sucker would lie around for far longer than you might want. > So, does this scheme sound sensible or should I just swallow my pride > and settle for using m_devget(). It would be nice to find a way to > actually squeeze some decent performance out of this gawdawful device > just to spite the designers. If anybody has tried to do something like > this before, or is familiar with the guts of the BSD networking code, > I'd appreciate any insights. I think that their rationalisation for using busmaster DMA was simply to avoid the need for SRAM on the card, thus lowering manufacturing costs. I fear that pride-swallowing may be in order. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message