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

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

Hi,

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

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>