From owner-freebsd-net Tue Jun 15 19:28:20 1999 Delivered-To: freebsd-net@freebsd.org Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (Postfix) with ESMTP id 155C8151A2 for ; Tue, 15 Jun 1999 19:28:09 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-esmtp (Exim 2.12 #1) id 10u5Qi-0003NQ-00; Wed, 16 Jun 1999 09:27:56 +0700 Date: Wed, 16 Jun 1999 09:27:56 +0700 (ALMST) From: Boris Popov To: "Justin C. Walker" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Multiple ethernet frames for IPX In-Reply-To: <199906160120.SAA00645@walker3.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 15 Jun 1999, Justin C. Walker wrote: > > Yes, it is really works now. This is first public release of > > if_ef driver which extends current functionality of existing ethernet > > drivers. > > I have a couple of questions: > > How does this handle the problem of getting a forwarded packet back > into the wrapper it needs (e.g., 802.3/SNAP)? Packet sended/forwarded to interface. Since frame type determined from the interface it is not a problem for ether_output() rotine to select appropriate frame to wrap in. > > Why is this better than, e.g., having stacks register for > packet-type reception? I'd think this would perform better than the > "virtual device" scheme. A (minor?) drawback is updating both stack > and "driver family support" (e.g., ether_input()) to handle this. No, you will also need to rewrite route* procedures. And changes required to protocol stack(s) aren't "minor" in this case. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message