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
next prev parent 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