From: Olivier Matz <olivier.matz@6wind.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, dev <dev@dpdk.org>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Bing Zhao <bingz@nvidia.com>, Xiaoyun Li <xiaoyun.li@intel.com>
Subject: Re: [dpdk-dev] [PATCH] ethdev: warn only once for badly behaving applications
Date: Wed, 27 Oct 2021 10:16:02 +0200 [thread overview]
Message-ID: <YXkKwpILAopmV/mF@platinum> (raw)
In-Reply-To: <CAJFAV8xpfLgxGR=vB0u558HKc=0jEMmvjqjYtjqExomtWuVe8Q@mail.gmail.com>
Hi,
On Wed, Oct 27, 2021 at 09:20:52AM +0200, David Marchand wrote:
> On Tue, Oct 26, 2021 at 5:57 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 26/10/2021 16:58, David Marchand:
> > > Warning continuously is a pain when developping or if a unit test
> > > is/gets broken.
> > >
> > > It could also be a problem if application behaves badly only in some
> > > corner cases and a DoS results of those logs being continuously displayed.
> > >
> > > Let's warn once per port and per rx/tx.
> > >
> > > Getting such a log is scary, but let's make it more eye catching by
> > > dumping a backtrace with it.
> > [...]
> > > Fixes: c87d435a4d79 ("ethdev: copy fast-path API into separate structure")
> > >
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > [...]
> > > +static struct dummy_queue *dummy_queues_ref[RTE_MAX_ETHPORTS][RTE_MAX_QUEUES_PER_PORT];
> > > +static struct dummy_queue dummy_queues[RTE_MAX_ETHPORTS];
> >
> > I feel we could better name those arrays, maybe adding a comment.
> > First one is really queues array while the second one is to share
> > the same value with all queues of a port. Right?
>
> Yes, look fwd to v2 for better names.
>
>
> >
> > > +RTE_INIT(dummy_queue_init)
> > > +{
> > > + uint16_t port_id;
> > > +
> > > + for (port_id = 0; port_id < RTE_DIM(dummy_queues); port_id++) {
> > > + unsigned int i;
> >
> > q would be a better name than i
>
> Ok, and I'll rename other variable q for actual queue objects later in
> the patch.
>
>
> > > eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
> > > {
> > > static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
> > > - static const struct rte_eth_fp_ops dummy_ops = {
> > > + uint16_t port_id = fpo - rte_eth_fp_ops;
> > > +
> > > + dummy_queues[port_id].rx_warn_once = false;
> > > + dummy_queues[port_id].tx_warn_once = false;
> > > + *fpo = (struct rte_eth_fp_ops) {
> > > .rx_pkt_burst = dummy_eth_rx_burst,
> > > .tx_pkt_burst = dummy_eth_tx_burst,
> > > - .rxq = {.data = dummy_data, .clbk = dummy_data,},
> > > - .txq = {.data = dummy_data, .clbk = dummy_data,},
> > > + .rxq = (struct rte_ethdev_qdata) {
> >
> > Why this cast? rte_eth_fp_ops.rxq is of type rte_ethdev_qdata.
>
> Funny how the compiler complains about:
>
> ../lib/ethdev/ethdev_private.c: In function ‘eth_dev_fp_ops_reset’:
> ../lib/ethdev/ethdev_private.c:243:9: error: expected expression
> before ‘{’ token
> *fpo = {
> ^
> if we don't explicitely tell this anonymous struct is of type struct
> rte_eth_fp_ops (note that *fpo is of type struct rte_eth_fp_ops).
> But otoh, compiler silently understands that, in .rxq case, the
> anonymous struct is of type rte_ethdev_qdata.
>
> So indeed, it works without the cast on .rxq and .txq.
> I applied the cast on all anonymous struct in my patch once I hit the
> first compiler complaint.
>
> Do you have the explanation or can you point me at some standard
> explaining the difference in treatment?
Let me try an explanation, hope it is the correct one.
In the first case, this is an assignment as described in 6.5.16 of
the standard [1]:
*fpo = (struct rte_eth_fp_ops) { .rx_pkt_burst = dummy_eth_rx_burst, ... };
The compiler expects the right side to be an expression. The expression
is a "compound literal", as described in 6.5.2.5:
1. The type name shall specify a complete object type or an array of
unknown size, but not avariable length array type.
2. All the constraints for initializer lists in 6.7.9 also apply to
compound literals
The second cast { ..., .rxq = (struct rte_ethdev_qdata) { ... } } is
inside a construction that behaves like an initialization (according to
the second point above). The compiler already knows the type of the
struct (and therefore the types of the fields), so the cast is not
required.
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> >
> > > + .data = (void **)&dummy_queues_ref[port_id],
> > > + .clbk = dummy_data,
> > > + },
> > > + .txq = (struct rte_ethdev_qdata) {
> > > + .data = (void **)&dummy_queues_ref[port_id],
> > > + .clbk = dummy_data,
> > > + },
> > > };
> > > -
> > > - *fpo = dummy_ops;
> > > }
>
>
> --
> David Marchand
>
next prev parent reply other threads:[~2021-10-27 8:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 14:58 David Marchand
2021-10-26 15:56 ` Thomas Monjalon
2021-10-27 7:20 ` David Marchand
2021-10-27 8:16 ` Olivier Matz [this message]
2021-10-27 8:42 ` David Marchand
2021-10-26 17:10 ` Ananyev, Konstantin
2021-10-27 7:23 ` David Marchand
2021-10-27 12:01 ` [dpdk-dev] [PATCH v2] ethdev: warn once for buggy applications David Marchand
2021-10-27 12:15 ` Ananyev, Konstantin
2021-10-27 12:46 ` Thomas Monjalon
2021-10-27 17:31 ` Ferruh Yigit
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=YXkKwpILAopmV/mF@platinum \
--to=olivier.matz@6wind.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bingz@nvidia.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=thomas@monjalon.net \
--cc=xiaoyun.li@intel.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;
as well as URLs for NNTP newsgroup(s).