Re: IFQ_ENQUEUE argument refactor (was Re: RFC: ALTQ caller refactor)

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2016/04/11 13:06, Kengo NAKAHARA wrote:
> On 2016/04/07 8:50, Kengo NAKAHARA wrote:
>> Hi,
>>
>> On 2016/04/05 16:38, Joerg Sonnenberger wrote:
>>> On Tue, Apr 05, 2016 at 01:11:01PM +0900, Kengo NAKAHARA wrote:
>>>> (Q2) How do I decide the data is too large or not?
>>>> e.g. ALTQ case, the data is struct altq_pktattr whose members are void *,
>>>> int, and void *.
>>>>     http://nxr.netbsd.org/xref/src/sys/altq/if_altq.h#86
>>>> Is this three member struct too large?
>>>> another PACKET_TAG_PF m_tag case, the data is struct pf_mtag
>>>>     http://nxr.netbsd.org/xref/src/sys/dist/pf/net/pf_mtag.h#46
>>>> How about this pattern?
>>>
>>> Look at struct pkthdr. It's currently 2 pointers and 4 ints in the first
>>> mbuf of every packet. We want to avoid pushing too much into it as the
>>> rest of the mbuf is used for data, so "reasonable" small packets, we
>>> want to completely stay in the first mbuf. The total size of a mbuf is
>>> currently either 256 or 512 Bytes, mbuf header is < 60 Bytes, so
>>> assuming that reasonable small means < 80 Bytes, we have around 120
>>> Bytes or so to spend on the packet header.
>>
>> Thank you very much for your great helpful comments.
>>
>> How about Q1?
> 
> I implement moving struct altq_pktattr from m_tag to mbuf. Here is
> the patch.
>     http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/mbuf-altq-pktattr.patch

I also upload separated patch series.
    http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/0001-use-altq_pktattr-as-mbuf.patch
    http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/0002-fix-caller-side.patch
    http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/0003-more-refactor-to-fix-performance-issue.patch
    http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/0004-improve-comment.patch

> As the comment in above patch, new mbuf size is 36 bytes for ILP32 and
> 56 bytes for LP64. They are less than 80 bytes which joerg@n.o pointed
> out.
> # I will add ethernet RSS Hash Value (32 bits) and RSS type (maybe 4
> # bits) to use multiqueue more effectively. I will also add gif(4)
> # nested count (8 bits or 16 bits) which use m_tag currently. If all
> # of them are added, it is still less than 80 bytes.
> 
> Could you comment the patch?
> 
> Hmm, The patch would conform to joerg@n.o's and tls@n.o's comments.
> If there is no other objection, I will commit above patch after a few
> days or a few weeks.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>