From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3FE7EA0547; Wed, 27 Oct 2021 09:21:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0780A40E0F; Wed, 27 Oct 2021 09:21:11 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 7904340DDA for ; Wed, 27 Oct 2021 09:21:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635319269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OtFAUt11cfsxuroJFlIXSCVW7jvrUYEKFjsEzaQioao=; b=BhzOxz4hI1P9HXI+/2g8xXVjveGoz3BT0agDIXd3UUtEQcK17tywRnVf9M+iTf2u6vmrFH vlkbMTqh1cVXbwF0SLlu22cAjG3MecfGPKrykDD470EzC5pYtkwGtreSOA7ArsSaaT/S9d i4s4NHWgMXxLkUN+2464oEydEoao/HU= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-114-r_tSohN7OduxbFBmaKCgqw-1; Wed, 27 Oct 2021 03:21:05 -0400 X-MC-Unique: r_tSohN7OduxbFBmaKCgqw-1 Received: by mail-lj1-f198.google.com with SMTP id a3-20020a2e8603000000b00212aa7719f3so77276lji.10 for ; Wed, 27 Oct 2021 00:21:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OtFAUt11cfsxuroJFlIXSCVW7jvrUYEKFjsEzaQioao=; b=EmqE5nllyK4ZkcmKVz38D9iih1UUzYiXNwrEQIcFhX5AaaLWyllo2UBrNON3t9gpga sKAlWZuXOwh89qdUPAgCoLtYdyQABvaNVlwEGgIWaD/0MCE3T6jHrcoQOaTQqAVQC866 DdTo4OrN4JVFZHNzhAlcI/mVNqrI0BsoayQoRWaBYsLAS8oUqpBU3E+iH7kSJBCvwYmQ qNXYrX76KAzwb6oo5j+blvS6O6I/mlblmkXhIromsft5ACHn2M89A3lmRR/MznHYl3uj kjy+QSg4mT1Nu3q4IKvXYgmM+lblVe4GpXzvyvYDXfuefXDJxU/6Gy71Gph7VluQdVA0 jngw== X-Gm-Message-State: AOAM532xf4oZ79BHU9q5EQF2W/p/ujKP6kViC5RE3GzWDv/XSXqEPNwf c+DwFT13QHOIqxKk0qTkxmB2pJQQf04XbQIZzbErb2cuYISOTgGFwoQTbNkUd1nYcl3RVMFeQDq ts+J74u3IvnPElokQ6Mk= X-Received: by 2002:a2e:b6cc:: with SMTP id m12mr30035139ljo.297.1635319264206; Wed, 27 Oct 2021 00:21:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxACcvjtERnZdcZ45R31qOZCLJfL7TSJqrEAhW1DKDOKVPwmHpgOh1zy89Du4sBPBSAh7GobpV8ZIE8/PDEIsA= X-Received: by 2002:a2e:b6cc:: with SMTP id m12mr30035116ljo.297.1635319263983; Wed, 27 Oct 2021 00:21:03 -0700 (PDT) MIME-Version: 1.0 References: <20211026145851.21944-1-david.marchand@redhat.com> <3415992.2jfn0xn0IN@thomas> In-Reply-To: <3415992.2jfn0xn0IN@thomas> From: David Marchand Date: Wed, 27 Oct 2021 09:20:52 +0200 Message-ID: To: Thomas Monjalon Cc: dev , "Ananyev, Konstantin" , "Yigit, Ferruh" , Andrew Rybchenko , Bing Zhao , Xiaoyun Li Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] ethdev: warn only once for badly behaving applications X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Oct 26, 2021 at 5:57 PM Thomas Monjalon 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 display= ed. > > > > 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 structur= e") > > > > Signed-off-by: David Marchand > [...] > > +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 =3D 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 =3D { > > + uint16_t port_id =3D fpo - rte_eth_fp_ops; > > + > > + dummy_queues[port_id].rx_warn_once =3D false; > > + dummy_queues[port_id].tx_warn_once =3D false; > > + *fpo =3D (struct rte_eth_fp_ops) { > > .rx_pkt_burst =3D dummy_eth_rx_burst, > > .tx_pkt_burst =3D dummy_eth_tx_burst, > > - .rxq =3D {.data =3D dummy_data, .clbk =3D dummy_data,}, > > - .txq =3D {.data =3D dummy_data, .clbk =3D dummy_data,}, > > + .rxq =3D (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 =E2=80=98eth_dev_fp_ops_reset= =E2=80=99: ../lib/ethdev/ethdev_private.c:243:9: error: expected expression before =E2=80=98{=E2=80=99 token *fpo =3D { ^ 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? > > > + .data =3D (void **)&dummy_queues_ref[port_id], > > + .clbk =3D dummy_data, > > + }, > > + .txq =3D (struct rte_ethdev_qdata) { > > + .data =3D (void **)&dummy_queues_ref[port_id], > > + .clbk =3D dummy_data, > > + }, > > }; > > - > > - *fpo =3D dummy_ops; > > } --=20 David Marchand