svn commit: r242739 - stable/9/sys/dev/ti

[Andre Oppermann]

On 08.11.2012 05:53, Adrian Chadd wrote:
> On 7 November 2012 18:38, YongHyeon PYUN <pyunyh at 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