Hi, Thank you for comments.
On 2016/04/11 17:11, Joerg Sonnenberger wrote: > On Mon, Apr 11, 2016 at 01:06:00PM +0900, Kengo NAKAHARA wrote: >> 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 > > The only issue here is that I would prefer to not add the ALTQ > include, but just move the definition into sys/mbuf.h. Out of curiosity, I see. I remove ALTQ include. Since I add individual fields in struct pkthdrAs as you indicated following, I don't move strct altq_pktattr. > is the new size the same if you add the fields individually and the int > first? I.e. does using the struct add initial padding? It might be > useful at some point later to drop altq_pktattr as separate type > altogether and just use individual fields. As soon as some data after > pattr has to be added, we get padding on LP64 otherwise. Fair enough. The new size is the same when I add the fields individually an the int first. I change the fields order in several patterns, but the new size is the same unless adding __packed attribute. # with __packed, the size changes from 56 bytes to 52 bytes in LP64, # in contrast, the size is the same in ILP32 However, I get padding when I add new uint32_t fields after pattr in LP64. So, I modify to use individual fields for future works. I ensured this changes does not cause performance issues in my measurement. Here is the updated patch and patch series. - unified patch http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/mbuf-altq-pktattr-2.patch - 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 http://www.netbsd.org/~knakahara/mbuf-altq-pktattr/0005-reviewed-by-joerg-n.o.patch Could you comment this patch? Thanks, -- ////////////////////////////////////////////////////////////////////// Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA <k-nakah...@iij.ad.jp>