Date: Tue, 21 Nov 2000 13:06:03 -0800 From: Julian Elischer <julian@elischer.org> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: net@freebsd.org Subject: Re: ALTQ as standard..... Message-ID: <3A1AE3BB.299944A4@elischer.org> References: <200011211443.eALEhV510844@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon wrote: > > > Do you have a potential replacement for the IFQ_* macros > in mind? I'm updating the IF_* macros to be SMP safe, but > still haven't changed the FIFO ordering. Basically kenjiro's maro set.. > > The patch is at http://www.flugsvamp.com/~jlemon/fbsd/ifq_v4.patch I'll have a look > > One change in these macros is the introduction of an IF_HANDOFF() > macro that performs all the queueing, so in theory it should be > easier in the future to conditionalize this to perform different > types of packet queuing. I'm going to need to interface with this stuff and I want to implement such things as highwater marks and such. Netgraph interfaces with 'standard' interfaces in the ethernet driver forinstance. the queue is the handoff point. I'm trying to provide some standard queuing support in netgraph so it seems to me that something like Kenjiro's changes would be good to do at the same time or before. His patches seem pretty complete from what I saw. > > However, as Kenjiro pointed out earlier, all the drivers need > to be updated to perform correct dequeueing (rather than the various > ad-hoc "look at head, dequeue, prepend if no space, etc". This > requires significantly more code changes than updating some macro > sets. true but he's already spent a lot of time on this and has from what I see, a lot of it already under control (see 'supported interface cards') > > As far as Netgraph goes, I note that each netgraph node seems to > require two queues; fast and slow. No, no queueing is required on the average node. You may be confused by the two input methods.. they are TERRIBLY named and archie got the description confused in his doc. here's what I added to the file this very afternoon. (I changed the names and added theses comments at various places.) ----------- . /* * Structure of a node type. + * If data is sent to the "rcvdata_may_queue ()" entrypoint then the node + * may decide to defer it until later by queing it with the normal netgraph + * input queuing system. When it is dequeued it will be + * passed to the "rcvdata_dont_queue()" method to ensure it is not + * requeued again. Nodes may supply the same method for both + * entrypoints if they have no need to queue incoming data. + * Note that the input queueing system is to allow modules + * to 'release the stack' or to pass data across spl layers. + * The data will be redelivered as soon as the NETISR code runs + * which may be almost immediatly. A node may also do it's own queueing + * for other reasons (e.g. device output queuing), but most nodes will * * not do any queueing */ struct ng_type { @@ -170,8 +181,8 @@ ng_newhook_t *newhook; /* first notification of new hook */ ng_findhook_t *findhook; /* only if you have lots of hooks */ ng_connect_t *connect; /* final notification of new hook */ - ng_rcvdata_t *rcvdata; /* date comes here */ - ng_rcvdata_t *rcvdataq; /* or here if being queued */ + ng_rcvdata_t *rcvdata_may_queue; /* data usually comes here */ + ng_rcvdata_t *rcvdata_dont_queue; /* but here if was queued */ ng_disconnect_t *disconnect; /* notify on disconnect */ const struct ng_cmdlist *cmdlist; /* commands we can convert */ @@ -182,47 +193,58 @@ }; > Also, who is responsible for > freeing the metadata for a packet? the consumer. or the last node to see it when an error occurs. If I could change the definition of an mbuf, it'd be pointed to by a field in the mbuf. so whoever frees the mbuf should free it. > -- > Jonathan -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A1AE3BB.299944A4>