Re: ALTQ

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Thu, Feb 10, 2005 at 10:18:45AM -0800, Matthew Dillon wrote:
:>     It looks ok except for the various IFQ_*() macros.  Passing a variable
:>     name as an argument to a macro (e.g. err) which then assigns the 
:>     variable creates a lot of confusion.  The NFSM code did this (albeit 
:>     much more aggregiously) and it created a real mess.
:
:It still makes the variable used for error handling explicit.
:The macros are compatible with KAME, I'd prefer to keep the current form.
:They are used in two cases which a normal network driver should not trigger.
:re(4) is a bit special because it tries to test the card first.
:
:>     Could you make those IFQ_*() macros real procedures instead of macros?
:>     Or at least real inline procedures.
:
:Real functions is not an option, because it would enforce the overhead
:for all interfaces, independent of ALTQ being available or not. Inline
:functions would work, but still need a macro since IFQ_ENQUEUE's pattr
:attribute is not available in non-ALTQ code. I'm not sure if that makes
:the code really any easier to read.
:
:Joerg

    I really don't like those large macros.  They seems so unnecessary to me.
    They take me back to the old VAX days when procedure calls were so 
    expensive you had to create huge macros to get any efficiency out of
    things.  I mean, I *REALLY* don't like those large macros.

    Take IFQ_ENQUEUE() for example.  Why is it a macro at all?  It's doing
    enough work that the extra 5ns it costs to make it a procedure is not
    going to hurt a bit.

    And why is the interface code calling IFQ_CLASSIFY ?  Why not have an
    ifq_enqueue() *function*, a real function, and call IFQ_CLASSIFY
    *inside* that function?

    Part of what we are doing in DragonFly is trying to simplify interfaces.
    The last thing I want to do is to have to add all this junk to every
    single IF module when it could all simply be incorporated into a 
    single function.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>