svn commit: r277122 - projects/ifnet/sys/dev/msk

[Gleb Smirnoff]

  John,

On Tue, Jan 13, 2015 at 01:22:09PM -0500, John Baldwin wrote:
J> >   o Convert from xxx_start(ifp) to xxx_transmit(ifp, m).
J> >     A simple conversion itself is quite straight:
J> >     * In ifdriver declaration define .ifdrv_maxqlen, take the value
J> >       from IFQ_SET_MAXLEN() macro.
J> >     * In ifdriver ifops declaration define if_transmit function.
J> >     * Rename xxx_start() to xxx_transmit() and change its prototype.
J> >     * The new named xxx_transmit() should:
J> >       - Try to if_snd_enqueue() the mbuf or return.
J> >       - Try to mtx_lock() the driver softc or return.
J> 
J> Please no.  This is a major source of pain with the current drivers that use 
J> buf_ring that is worked around in various (often broken) ways.  The problem
J> is that the other thread holding the lock might drop it right after your try 
J> lock fails and then the packet you just queued doesn't go out until you queue 
J> another packet.  That's all fine and good if you are blasting packets out an 
J> interface.  It is not fine and good if you have sparse traffic.  That packet 
J> is now potentially delayed indefinitely.  (In a real world scenario with a 
J> heartbeat protocol that sent out timing packets once a second or so to measure 
J> RTT between hosts this manifested as odd timings because we would see the 
J> timings jump by a second every so often when the packet was delayed until the 
J> next heartbeat).

Yes, I also see this problem when coding that.

J> This kind of design decision is why I do not want to just blindly convert 
J> everything to suboptimal if_transmit routines.  The current ifq based if_start 
J> model is better for 10/100 single-queue drivers than this.

If I convert mtx_trylock() to mtx_lock(), then we will get 1:1 conversion
to the current model. But, I still want to do an improvement while converting
drivers. :)

May be the xxx_transmit() should check the queue again after softc unlock?

-- 
Totus tuus, Glebius.