Hi,
On 2016/03/07 19:20, Joerg Sonnenberger wrote:
> On Tue, Feb 23, 2016 at 01:52:40PM +0900, Kengo NAKAHARA wrote:
>> Hi,
>>
>> I want to uniform IFQ_ENQUEUE arguments whether ALTQ is defined or not.
>> # And I also want to eliminate ALTQ_DECL and ALTQ_COMMA macros...
>> So, I make struct altq_pktattr from IFQ_CLASSIFY and IFQ_ENQUEUE argument
>> to m_tag. Here is the patch.
>>
>> http://netbsd.org/~knakahara/altq-caller-refactor/altq-caller-refactor.patch
>>
>> In above patch, I fix performance issue by the following two ways.
>> - make ALTQ's m_tag pool cache
>> - inline altq_*_pattr functions
>> Without these two fixes, the enabled ALTQ throughput degraded about 10%.
>> However, with these two fixes, the throughput is almost the same
>> performance.
>
> Is there a good reason to keep the complexity of the pattr attribute
> around? From working on the ALTQ code a few years ago I remember that it
> is only used by some of the more experimental mechanisms and not used by
> the few queueing disciplines people normally care about. It might be
> easier to just get rid of it.
No, there is no good reason. But, that is out of my scope now.
Sorry about confusing mail title, I want to remove pattr argument from
IFQ_ENQUEUE to support TX multiqueue. The lack of TX multiqueue causes
critical scaling problem because of lock contention in IFQ_ENQUEUE and
ifp->if_start. To avoid this lock contention, that is, support TX
multiqueue, I think it is require to support ifp->if_transmit() which
pass mbuf to ifp directly without IFQ_ENQUEUE. To implement this
interface with backward compatibility(keep IFQ_ENQUEUE + ifp->if_start
interface for many network device drivers), it is required to remove
pattr from IFQ_ENQUEUE.
BTW, I am not sure that it is the best solution to put struct altq_pktattr
to mbuf to simplify ALTQ... As you may know, the comment in ip_input()
says "ALTQ is changed to use a pfil hook".
http://nxr.netbsd.org/xref/src/sys/netinet/ip_input.c#554
FreeBSD and OpenBSD modified ALTQ by such way. However, I am not sure
that whether the way fits to NetBSD...
Thanks,
--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.
Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit
Kengo NAKAHARA <k-nakah...@iij.ad.jp>
