What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc?

[John Baldwin]

On Monday, September 17, 2012 4:29:50 pm Jack Vogel wrote:
> On Mon, Sep 17, 2012 at 1:22 PM, John Baldwin <jhb at freebsd.org> wrote:
> 
> > On Monday, September 17, 2012 4:00:04 pm Jack Vogel wrote:
> > > So, you mean having them create their own buf ring I assume? Would be
> > easy
> > > enough to hack some code and try it if someone is so inclined?
> >
> > No, that would be backwards (back to giving them a queue).  Adrian's
> > suggestion is to provide a mechanism so that the "real" interface
> > (e.g. emX) can call back into the psuedo-interfaces on top of it
> > (vlanX or bridgeX) when a TX completion interrupt fires so that the
> > pseudo-interface would know to restart transmission.  However, I think
> > this is generally not ideal.  I don't think we want an additional queue
> > of pending packets in things like if_bridge(4) and vlan(4).  If the
> > underlying physical interface(s) are full, the packet should just get
> > dropped rather than queued.  Using if_transmit directly will do that while
> > avoiding overhead.  Also, making the callback work would also be a bit
> > ungainly.
> >
> >
> I meant using if_transmit, not the callback, would it not then need a buf
> ring?

No.  You only need a buf_ring if you want a software queue of packets.  In
the case of virtual interfaces you don't really want that (it leads to
double queueing).  Instead, you want things like vlan(4) to just be a simple
transform that slaps on a vlan header and then passes the packet to the
underlying interface.

You wouldn't want to have a software queue at various protocol layers that
slap on headers (e.g. Ethernet or IP), and things like vlan(4) shouldn't have
one either.

-- 
John Baldwin