Linux USB
 help / color / mirror / Atom feed
From: Linyu Yuan <quic_linyyuan@quicinc.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Peter Chen <peter.chen@kernel.org>,
	Pawel Laszczak <pawell@cadence.com>,
	Roger Quadros <rogerq@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	Neal Liu <neal_liu@aspeedtech.com>,
	Cristian Birsan <cristian.birsan@microchip.com>,
	Bin Liu <b-liu@ti.com>, Kevin Cernekee <cernekee@gmail.com>,
	Justin Chen <justin.chen@broadcom.com>,
	Al Cooper <alcooperx@gmail.com>, Li Yang <leoyang.li@nxp.com>,
	Vladimir Zapolskiy <vz@mleia.com>,
	Daniel Mack <daniel@zonque.org>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Herve Codina <herve.codina@bootlin.com>,
	hierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Michal Simek <michal.simek@amd.com>,
	Rui Miguel Silva <rui.silva@linaro.org>,
	Valentina Manea <valentina.manea.m@gmail.com>,
	Shuah Khan <shuah@kernel.org>, Hongren Zheng <i@zenithal.me>,
	<linux-usb@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH v3 01/10] usb: gadget: add anonymous definition in struct usb_gadget
Date: Wed, 13 Sep 2023 11:46:12 +0800	[thread overview]
Message-ID: <d1c34d15-e598-5f86-bc86-cd5e656225c9@quicinc.com> (raw)
In-Reply-To: <2023091255-unsubtly-daisy-7426@gregkh>


On 9/12/2023 7:09 PM, Greg Kroah-Hartman wrote:
> On Tue, Sep 12, 2023 at 06:44:46PM +0800, Linyu Yuan wrote:
>> Some UDC trace event will save usb gadget information, but it use one int
>> size buffer to save one bit information of usb gadget, so 19 int buffers
>> needed to save 19 bit fields which is not good.
>>
>> Add one anonymous union which have one u32 member 'dw1' to struct
>> 'usb_gadget', it inlclude all 19 bits and can be used by trace event
>> during fast assign stage to save more entries with same trace ring buffer
>> size.
>>
>> Also move all original 19 bit fields into one anonymous struct which
>> inside struct 'usb_gadget'.
>>
>> In order to allow trace event output stage access the bit from saved u32
>> 'dw1', add following macro,
>> define USB_GADGET_BITFIELD(n, name) \
>> 	({\
>> 	union {\
>> 		struct {\
>> 			u32	sg_supported:1;\
>> 			u32	is_otg:1;\
>> 			u32	is_a_peripheral:1;\
>> 			u32	b_hnp_enable:1;\
>> 			u32	a_hnp_support:1;\
>> 			u32	a_alt_hnp_support:1;\
>> 			u32	hnp_polling_support:1;\
>> 			u32	host_request_flag:1;\
>> 			u32	quirk_ep_out_aligned_size:1;\
>> 			u32	quirk_altset_not_supp:1;\
>> 			u32	quirk_stall_not_supp:1;\
>> 			u32	quirk_zlp_not_supp:1;\
>> 			u32	quirk_avoids_skb_reserve:1;\
>> 			u32	is_selfpowered:1;\
>> 			u32	deactivated:1;\
>> 			u32	connected:1;\
>> 			u32	lpm_capable:1;\
>> 			u32	wakeup_capable:1;\
>> 			u32	wakeup_armed:1;\
>> 		} __packed;\
>> 		u32		dw1;\
>> 	} __aligned(4) __g_u_##name;\
>> 	u32 __g_##name; \
>> 	BUILD_BUG_ON(sizeof(__g_u_##name) != 4);\
>> 	__g_u_##name.dw1 = (n); __g_##name = __g_u_##name.name;\
>> 	__g_##name; })
>>
>> define USB_GADGET_SG_SUPPORTED(n) USB_GADGET_BITFIELD((n), sg_supported)
>> ...
>> change to use this kind of macro for all related trace files later.
> I'm sorry, but that's horrible, and is NOT how you deal with bitfields
> in an endian-neutral way at all.
>
> There are much simpler, and easier, ways to do this properly.


do you mean define two sets of ordering bit field according BIG and 
LITTLE ENDIAN like below ?


#if defined(__LITTLE_ENDIAN_BITFIELD)

         struct {
             u32        sg_supported:1;

            u32        is_otg:1;

             ..

             u32        :13;

         } __packed;

#else

         struct {
             u32        :13;
             ..

             u32        is_otg:1;

             u32        sg_supported:1;

         } __packed;

#endif

but Alan Stern have one comment,   do it mean the bit position number is 
not expect and we can't use it ?

@Alan Stern ,  BIT(0), BIT(1) is not the member we expect ?

"

  As far as I
know, the C compiler does not specify that bit fields in packed
structures will be assigned starting from the low-order bit position

"



>
> But I'm still missing the huge _WHY_ any of this is needed.  You are not
> showing any real advantage at all that I have noticed.
>
> You need to step back and see if any of this is even anything that needs
> to change, and if you feel it does need to change, you need to be able
> to properly justify _why_ it needs to change.


indeed this is a small optimization.


I think i explain the benefit in previous version, when user not 
increase system trace event buffer space,

or in lower system trace event buffer space, it allow more trace event 
entries  to be saved.


in normal condition, the usb request is most frequent things after 
enumeration with useful operation,

so take below trace event class for explanation,


DECLARE_EVENT_CLASS(udc_log_req,
     TP_PROTO(struct usb_ep *ep, struct usb_request *req, int ret),
     TP_ARGS(ep, req, ret),
     TP_STRUCT__entry(
         __string(name, ep->name)
         __field(unsigned, length)
         __field(unsigned, actual)
         __field(unsigned, num_sgs)
         __field(unsigned, num_mapped_sgs)
         __field(unsigned, stream_id)
         __field(unsigned, no_interrupt)
         __field(unsigned, zero)
         __field(unsigned, short_not_ok)
         __field(int, status)
         __field(int, ret)
         __field(struct usb_request *, req)
     ),
     TP_fast_assign(
         __assign_str(name, ep->name);
         __entry->length = req->length;
         __entry->actual = req->actual;
         __entry->num_sgs = req->num_sgs;
         __entry->num_mapped_sgs = req->num_mapped_sgs;
         __entry->stream_id = req->stream_id;
         __entry->no_interrupt = req->no_interrupt;
         __entry->zero = req->zero;
         __entry->short_not_ok = req->short_not_ok;
         __entry->status = req->status;
         __entry->ret = ret;
         __entry->req = req;
     ),
     TP_printk("%s: req %p length %d/%d sgs %d/%d stream %d %s%s%s 
status %d --> %d",
         __get_str(name),__entry->req,  __entry->actual, __entry->length,
         __entry->num_mapped_sgs, __entry->num_sgs, __entry->stream_id,
         __entry->zero ? "Z" : "z",
         __entry->short_not_ok ? "S" : "s",
         __entry->no_interrupt ? "i" : "I",
         __entry->status, __entry->ret
     )
);


consider 32 bit ARCH,

without change, one trace entry size is:

4 (ring buffer event header ) + 8 (trace event header ) + 48 (trace 
class header) + 9 (ep string name) = 69 bytes.


with change,

4 (ring buffer event header ) + 8 (trace event header ) + 36 (trace 
class header)  = 48 bytes.



consider there is 1MB trace buffer space,

without change, it can save 15196 entries,

with change, it can save 21845 entries.




>
> good luck!
>
> greg k-h

  reply	other threads:[~2023-09-13  3:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 10:44 [PATCH v3 00/10] usb: gadget: reduce usb gadget trace event buffer usage Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 01/10] usb: gadget: add anonymous definition in struct usb_gadget Linyu Yuan
2023-09-12 11:09   ` Greg Kroah-Hartman
2023-09-13  3:46     ` Linyu Yuan [this message]
2023-09-13 16:02       ` Alan Stern
2023-09-14  1:08         ` Linyu Yuan
2023-09-14  2:16           ` Alan Stern
2023-09-14  2:25             ` Linyu Yuan
2023-09-14  3:44               ` Linyu Yuan
2023-09-12 15:32   ` Alan Stern
2023-09-13  4:16     ` Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 02/10] usb: gadget: add anonymous definition in struct usb_request Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 03/10] usb: gadget: add anonymous definition in struct usb_ep Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 04/10] usb: udc: trace: reduce buffer usage of trace event Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 05/10] usb: cdns3: cdnsp: " Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 06/10] usb: cdns3: trace: " Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 07/10] usb: dwc3: " Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 08/10] usb: cdns2: " Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 09/10] usb: mtu3: " Linyu Yuan
2023-09-12 10:44 ` [PATCH v3 10/10] usb: musb: " Linyu Yuan
2023-09-12 11:09   ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1c34d15-e598-5f86-bc86-cd5e656225c9@quicinc.com \
    --to=quic_linyyuan@quicinc.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=alcooperx@gmail.com \
    --cc=b-liu@ti.com \
    --cc=cernekee@gmail.com \
    --cc=chunfeng.yun@mediatek.com \
    --cc=cristian.birsan@microchip.com \
    --cc=daniel@zonque.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=haojian.zhuang@gmail.com \
    --cc=herve.codina@bootlin.com \
    --cc=i@zenithal.me \
    --cc=jonathanh@nvidia.com \
    --cc=justin.chen@broadcom.com \
    --cc=leoyang.li@nxp.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=neal_liu@aspeedtech.com \
    --cc=p.zabel@pengutronix.de \
    --cc=pawell@cadence.com \
    --cc=peter.chen@kernel.org \
    --cc=robert.jarzmik@free.fr \
    --cc=rogerq@kernel.org \
    --cc=rui.silva@linaro.org \
    --cc=shuah@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=thierry.reding@gmail.com \
    --cc=valentina.manea.m@gmail.com \
    --cc=vz@mleia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox