>>>>> "Kenjiro" == Kenjiro Cho <kjc@csl.sony.co.jp> writes:
    Kenjiro> Michael Richardson wrote:
    Kenjiro> Another requirement for a driver is to work under rate-limiting.
    Kenjiro> - IFQ_DEQUEUE() could return NULL even when IFQ_IS_EMPTY() is FALSE
    Kenjiro> under rate-limiting.  a driver should always check if (m == NULL).
    Kenjiro> - a driver is supposed to call if_start from the tx complete interrupt
    Kenjiro> under late-limiting (in order to trigger the next dequeue).

    >> I'd like to suggest that the interface model be a bit higher level.
    >> 
    >> My experience with seeing what the Linux queueing code is that it appears
    >> pretty hard to interface to a NIC card (be it I2O or otherwise) that can do 
    >> some queueing itself. While I don't see any of these on the market right now,
    >> I expect that there will be some in the future. 
    >> 
    >> Outbound queueing is likely something that will be offloaded from the main
    >> CPU pretty soon, as it can be pretty CPU intensive to get the rate correct.

    Kenjiro> If a driver does packet scheduling, all we need to do is to custimize
    Kenjiro> the enqueue and purge operations for the device and it is easily
    Kenjiro> supported in this model.  The driver won't need if_start (and the
    Kenjiro> dequeue operation) in this case.
    Kenjiro> Probably, we should define another level of abstraction for this kind of
    Kenjiro> devices. 

  The key is that there is some interface that gets the packets before they
are scheduled to be sent, which provides the scheduling info as well. If that 
entry point is NULL, then we maintain queues inside of ALTQ, and use the
"basic send" that you have proposed.

]     Internet Security. Have encryption, will travel           |1 Fish/2 Fish[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [