Date: Fri, 23 Jul 1999 10:22:54 -0700 From: Mike Smith <mike@smith.net.au> To: Kenjiro Cho <kjc@csl.sony.co.jp> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Mike Smith <mike@smith.net.au>, Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, jkh@FreeBSD.org Subject: Re: cvs commit: src/release/sysinstall tcpip.c Message-ID: <199907231722.KAA03340@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 23 Jul 1999 19:50:05 %2B0900." <199907231050.TAA00721@hotaka.csl.sony.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> If we are going to change the network driver API, I want to push it
> further. (I briefly touched this point at USENIX.)
> - queueing should be taken out of drivers
I don't like this one very much; it's one place where we would lose a
great amount of efficiency.
> Also, it would be nice to have a common interface layer (or it can be
> called "abstracted network device layer") that handles the following
> items:
> - bpf, bridging
> - fastforwarding
> - queueing, (multiprotocol) firewall
> (possible integration of ALTQ, dummynet, ipfw)
> - layered interfaces
> (subinterfaces (vlan or atm), multi-link, tunneling)
> This common interface layer will make future evolution easier.
>
> In this model, a driver simply passes a raw packet to
> if_input(), something like:
>
> if_input(ifp, m)
> {
> bpf_processing;
>
> /* link type specific processing */
> (*ifp->if_input)(ifp, &m, &inq);
> if (m == NULL)
> return;
>
> IF_ENQUEUE(inq, m);
> schednetisr(inq);
> }
This is more or less what I had in mind.
> On the sending side,
>
> if_output(ifp, m, dst, rt)
> {
> /* link type specific processing */
> (*ifp->if_output)(ifp, m, dst, rt);
>
> IF_ENQUEUE(&ifp->if_snd, m);
> }
>
> if_start(ifp)
> {
> IF_DEQUEUE(&ifp->if_snd, m);
> if (m == NULL)
> return;
> process_bpf;
>
> /* call driver's start routine that sends out one packet */
> (*ifp->if_start)(ifp, m);
> }
This last fragment is unacceptable though; it's one of the massive
inefficiencies in the Linux architecture and I don't think you'll ever
sell a proposal that requires CPU intervention between each and
every packet. By all means implement a per-interface flag that limits
the number of datagrams that can be in the interface's private send
queue at once (I think we already have one of those, actually) so that
you can adjust the latency involved.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ msmith@freebsd.org
\\ -- Joseph Merrick \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907231722.KAA03340>