On 08.11.2012 05:53, Adrian Chadd wrote:
On 7 November 2012 18:38, YongHyeon PYUN <pyu...@gmail.com> wrote:
On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote:
If so, may I suggest we perhaps accelerate discussing if_transmit() of
multiple frames per call?
Hmm, actually I'm still not a fan of if_transmit() at this moment.
Honestly I don't have good queuing code in driver to handle queue
full condition. Interactions with altq(9) is also one of my
concern as well as packet reordering issue of drbr(9) interface.
-snip-
I have a vague idea of making if_transmit() as an interface be able to
send multiple frames at once - so the TCP/UDP code could generate all
the fragments and fire them off at once to the NIC. This should fix
your issue and begin allowing devices to take advantage of
multiple-dispatch rather than one if_transmit() call at a time.
TCP/UDP doesn't (want to) generate any fragments at all and tries
to avoid it at almost all cost. We want to send very large packets
and have the NIC fragment/segment it (TSO/UDP frag offload).
We could create a device or interface flag that indicates whether the
driver can handle multiple mbufs chained via m_nextpkt through
if_transmit(), and then teach one or two drivers that particular
logic.
Agreed. I think that's the way to go. It must be very well specified
in semantics though. Otherwise it's just too easy to leak mbuf all
over the place.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
