From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Nelson Escobar <neescoba@cisco.com>,
John Daley <johndale@cisco.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Christian Benvenuti <benve@cisco.com>,
Satish Kharat <satishkh@cisco.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH net-next v3 1/7] enic: Create enic_wq/rq structures to bundle per wq/rq data
Date: Sat, 9 Nov 2024 20:27:50 +0000 [thread overview]
Message-ID: <10fdd0d6-cd63-40a4-b663-1f2755003e85@linux.dev> (raw)
In-Reply-To: <20241108-remove_vic_resource_limits-v3-1-3ba8123bcffc@cisco.com>
On 08/11/2024 21:47, Nelson Escobar wrote:
> Bundling the wq/rq specific data into dedicated enic_wq/rq structures
> cleans up the enic structure and simplifies future changes related to
> wq/rq.
>
> Co-developed-by: John Daley <johndale@cisco.com>
> Signed-off-by: John Daley <johndale@cisco.com>
> Co-developed-by: Satish Kharat <satishkh@cisco.com>
> Signed-off-by: Satish Kharat <satishkh@cisco.com>
> Signed-off-by: Nelson Escobar <neescoba@cisco.com>
> Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> drivers/net/ethernet/cisco/enic/enic.h | 18 ++--
> drivers/net/ethernet/cisco/enic/enic_ethtool.c | 4 +-
> drivers/net/ethernet/cisco/enic/enic_main.c | 120 ++++++++++++-------------
> drivers/net/ethernet/cisco/enic/enic_res.c | 12 +--
> 4 files changed, 81 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net/ethernet/cisco/enic/enic.h b/drivers/net/ethernet/cisco/enic/enic.h
> index 0cc3644ee8554f52401a0be7f44a1475ab2ea2b9..e6edb43515b97feeb21a9b55a1eeaa9b9381183f 100644
> --- a/drivers/net/ethernet/cisco/enic/enic.h
> +++ b/drivers/net/ethernet/cisco/enic/enic.h
> @@ -162,6 +162,17 @@ struct enic_rq_stats {
> u64 desc_skip; /* Rx pkt went into later buffer */
> };
>
> +struct enic_wq {
> + struct vnic_wq vwq;
> + struct enic_wq_stats stats;
> + spinlock_t lock; /* spinlock for wq */
> +};
> +
This change will make vnic_wq spinlock share the latest cache line of
queue statitics while protecting struct vnic_wq.
struct enic_wq {
struct vnic_wq vwq; /* 0 632 */
/* XXX last struct has 4 bytes of padding, 1 hole */
/* --- cacheline 9 boundary (576 bytes) was 56 bytes ago --- */
struct enic_wq_stats stats; /* 632 120 */
/* --- cacheline 11 boundary (704 bytes) was 48 bytes ago --- */
spinlock_t lock; /* 752 4 */
/* size: 760, cachelines: 12, members: 3 */
/* padding: 4 */
/* member types with holes: 1, total: 1 */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 56 bytes */
};
That is not good for performance. Simple re-arrange of the struct makes
lock and vnic_wq structure properly aligned:
struct enic_wq {
spinlock_t lock; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct vnic_wq vwq; /* 8 632 */
/* XXX last struct has 4 bytes of padding, 1 hole */
/* --- cacheline 10 boundary (640 bytes) --- */
struct enic_wq_stats stats; /* 640 120 */
/* size: 760, cachelines: 12, members: 3 */
/* sum members: 756, holes: 1, sum holes: 4 */
/* member types with holes: 1, total: 1 */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 56 bytes */
};
Adding one u64 pad field to enic_wq_stats makes whole enic_wq properly
aligned to 12 cache lines on x86.
It might be worth adding ____cacheline_aligned to struct enic_wq to keep
the same performance expectations after converting to dynamic allocation
later in the patchset.
> +struct enic_rq {
> + struct vnic_rq vrq;
> + struct enic_rq_stats stats;
> +};
> +
> /* Per-instance private data structure */
> struct enic {
> struct net_device *netdev;
next prev parent reply other threads:[~2024-11-09 20:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 21:47 [PATCH net-next v3 0/7] enic: Use all the resources configured on VIC Nelson Escobar
2024-11-08 21:47 ` [PATCH net-next v3 1/7] enic: Create enic_wq/rq structures to bundle per wq/rq data Nelson Escobar
2024-11-09 20:27 ` Vadim Fedorenko [this message]
2024-11-08 21:47 ` [PATCH net-next v3 2/7] enic: Make MSI-X I/O interrupts come after the other required ones Nelson Escobar
2024-11-11 17:47 ` Simon Horman
2024-11-08 21:47 ` [PATCH net-next v3 3/7] enic: Save resource counts we read from HW Nelson Escobar
2024-11-08 21:47 ` [PATCH net-next v3 4/7] enic: Allocate arrays in enic struct based on VIC config Nelson Escobar
2024-11-08 21:47 ` [PATCH net-next v3 5/7] enic: Adjust used MSI-X wq/rq/cq/interrupt resources in a more robust way Nelson Escobar
2024-11-11 17:48 ` Simon Horman
2024-11-08 21:47 ` [PATCH net-next v3 6/7] enic: Move enic resource adjustments to separate function Nelson Escobar
2024-11-11 17:49 ` Simon Horman
2024-11-08 21:47 ` [PATCH net-next v3 7/7] enic: Move kdump check into enic_adjust_resources() Nelson Escobar
2024-11-11 17:49 ` Simon Horman
2024-11-13 2:30 ` [PATCH net-next v3 0/7] enic: Use all the resources configured on VIC Jakub Kicinski
2024-11-14 18:45 ` Nelson Escobar (neescoba)
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=10fdd0d6-cd63-40a4-b663-1f2755003e85@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=benve@cisco.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=johndale@cisco.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neescoba@cisco.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=satishkh@cisco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.