On Monday, September 17, 2012 4:29:50 pm Jack Vogel wrote: > On Mon, Sep 17, 2012 at 1:22 PM, John Baldwin <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
