netdev - Re: [PATCH 0/3] net: Byte queue limit patch series

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20110501.204938.226758514.davem@davemloft.net>
Date:	Sun, 01 May 2011 20:49:38 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	therbert@...gle.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 0/3] net: Byte queue limit patch series

From: Tom Herbert <therbert@...gle.com>
Date: Sun, 1 May 2011 19:41:34 -0700

> On Fri, Apr 29, 2011 at 11:54 AM, David Miller <davem@...emloft.net> wrote:
>> Add new interface, netdev_free_tx_skb(txq, skb) which can do the
>> completion accounting.  Actually the 'txq' argument is probably
>> superfluous as it can be obtained from the skb itself.
>>
> Okay, but I think the call at the end of TX completion processing is
> still probably needed.  The algorithm is trying to determine the
> number of bytes that completed at each interrupt.

Ok, then call it something generic like netdev_tx_complete() which
can serve other purposes in the future and not be bql specific.

>> Finally, you manage the bql limit logic in the existing generic netdev
>> TX start/stop interfaces.  If the user asks for "start" but the bql
>> is overlimit, simply ignore the request.  The driver will just signal
>> another "start" when the next TX packet completes.
>>
>> Similarly, when the qdisc is queuing up a packet to
>> dev_hard_start_xmit() you can, for example, preemptively do a "stop"
>> on the queue if you find bql is overlimit.
>>
> Unfortunately, there is still an additional complexity if we don't
> piggy back on the logic in the driver to stop the queue.  I believe
> that either this would require another queue state for queue being
> stopped for bql which looks pretty cumbersome, so that wrapping this
> in a qdisc might be a better possibility.

I'll leave it up to you what approach to try next.

Even thought I sort of side with you that bql is a largely seperate
facility from what we usually do with qdiscs, this TX completion
event could be very useful as an input to qdisc decision making.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html