Re: [net-next 2/8] net/mlx5: Configure cache line size for start and end padding

2017-02-06 Thread Saeed Mahameed
On Mon, Feb 6, 2017 at 3:50 PM, David Laight  wrote:
> From: Saeed Mahameed
>> Sent: 05 February 2017 11:24
>> On Thu, Feb 2, 2017 at 4:47 PM, Daniel Jurgens  wrote:
>> > On 2/1/2017 5:12 AM, David Laight wrote:
>> >> From: Saeed Mahameed
>> >>> Sent: 31 January 2017 20:59
>> >>> From: Daniel Jurgens 
>> >>>
>> >>> There is a hardware feature that will pad the start or end of a DMA to
>> >>> be cache line aligned to avoid RMWs on the last cache line. The default
>> >>> cache line size setting for this feature is 64B. This change configures
>> >>> the hardware to use 128B alignment on systems with 128B cache lines.
>> >> What guarantees that the extra bytes are actually inside the receive skb's
>> >> head and tail room?
>> >>
>> >>   David
>> >>
>> >>
>> > The hardware won't over write the length of the posted buffer.  This 
>> > feature is already enabled and
>> defaults to 64B stride, this patch just configures it properly for 128B 
>> cache line sizes.
>> >
>> Right, and next patch will make sure RX stride is aligned to 128B in
>> case 128B cacheline size configured into the HW.
>
> Doesn't that mean these patches are in the wrong order?
>

Right, will fix that

>> > Thanks for reviewing it.
>
> Don't assume I've done anything other than look for obvious fubars/
>
> David
>


RE: [net-next 2/8] net/mlx5: Configure cache line size for start and end padding

2017-02-06 Thread David Laight
From: Saeed Mahameed 
> Sent: 05 February 2017 11:24
> On Thu, Feb 2, 2017 at 4:47 PM, Daniel Jurgens  wrote:
> > On 2/1/2017 5:12 AM, David Laight wrote:
> >> From: Saeed Mahameed
> >>> Sent: 31 January 2017 20:59
> >>> From: Daniel Jurgens 
> >>>
> >>> There is a hardware feature that will pad the start or end of a DMA to
> >>> be cache line aligned to avoid RMWs on the last cache line. The default
> >>> cache line size setting for this feature is 64B. This change configures
> >>> the hardware to use 128B alignment on systems with 128B cache lines.
> >> What guarantees that the extra bytes are actually inside the receive skb's
> >> head and tail room?
> >>
> >>   David
> >>
> >>
> > The hardware won't over write the length of the posted buffer.  This 
> > feature is already enabled and
> defaults to 64B stride, this patch just configures it properly for 128B cache 
> line sizes.
> >
> Right, and next patch will make sure RX stride is aligned to 128B in
> case 128B cacheline size configured into the HW.

Doesn't that mean these patches are in the wrong order?

> > Thanks for reviewing it.

Don't assume I've done anything other than look for obvious fubars/

David



Re: [net-next 2/8] net/mlx5: Configure cache line size for start and end padding

2017-02-05 Thread Saeed Mahameed
On Thu, Feb 2, 2017 at 4:47 PM, Daniel Jurgens  wrote:
> On 2/1/2017 5:12 AM, David Laight wrote:
>> From: Saeed Mahameed
>>> Sent: 31 January 2017 20:59
>>> From: Daniel Jurgens 
>>>
>>> There is a hardware feature that will pad the start or end of a DMA to
>>> be cache line aligned to avoid RMWs on the last cache line. The default
>>> cache line size setting for this feature is 64B. This change configures
>>> the hardware to use 128B alignment on systems with 128B cache lines.
>> What guarantees that the extra bytes are actually inside the receive skb's
>> head and tail room?
>>
>>   David
>>
>>
> The hardware won't over write the length of the posted buffer.  This feature 
> is already enabled and defaults to 64B stride, this patch just configures it 
> properly for 128B cache line sizes.
>
Right, and next patch will make sure RX stride is aligned to 128B in
case 128B cacheline size configured into the HW.

> Thanks for reviewing it.
>
> Dan
>


Re: [net-next 2/8] net/mlx5: Configure cache line size for start and end padding

2017-02-02 Thread Daniel Jurgens
On 2/1/2017 5:12 AM, David Laight wrote:
> From: Saeed Mahameed
>> Sent: 31 January 2017 20:59
>> From: Daniel Jurgens 
>>
>> There is a hardware feature that will pad the start or end of a DMA to
>> be cache line aligned to avoid RMWs on the last cache line. The default
>> cache line size setting for this feature is 64B. This change configures
>> the hardware to use 128B alignment on systems with 128B cache lines.
> What guarantees that the extra bytes are actually inside the receive skb's
> head and tail room?
>
>   David
>
>
The hardware won't over write the length of the posted buffer.  This feature is 
already enabled and defaults to 64B stride, this patch just configures it 
properly for 128B cache line sizes.

Thanks for reviewing it.

Dan



RE: [net-next 2/8] net/mlx5: Configure cache line size for start and end padding

2017-02-01 Thread David Laight
From: Saeed Mahameed
> Sent: 31 January 2017 20:59
> From: Daniel Jurgens 
> 
> There is a hardware feature that will pad the start or end of a DMA to
> be cache line aligned to avoid RMWs on the last cache line. The default
> cache line size setting for this feature is 64B. This change configures
> the hardware to use 128B alignment on systems with 128B cache lines.

What guarantees that the extra bytes are actually inside the receive skb's
head and tail room?

David



[net-next 2/8] net/mlx5: Configure cache line size for start and end padding

2017-01-31 Thread Saeed Mahameed
From: Daniel Jurgens 

There is a hardware feature that will pad the start or end of a DMA to
be cache line aligned to avoid RMWs on the last cache line. The default
cache line size setting for this feature is 64B. This change configures
the hardware to use 128B alignment on systems with 128B cache lines.

Signed-off-by: Daniel Jurgens 
Signed-off-by: Saeed Mahameed 
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 ++
 include/linux/mlx5/mlx5_ifc.h  | 6 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 84f7970c5080..ca09895b3a05 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -543,6 +543,12 @@ static int handle_hca_cap(struct mlx5_core_dev *dev)
 
MLX5_SET(cmd_hca_cap, set_hca_cap, log_uar_page_sz, PAGE_SHIFT - 12);
 
+   if (MLX5_CAP_GEN_MAX(dev, cache_line_128byte))
+   MLX5_SET(cmd_hca_cap,
+set_hca_cap,
+cache_line_128byte,
+cache_line_size() == 128 ? 1 : 0);
+
err = set_caps(dev, set_ctx, set_sz,
   MLX5_SET_HCA_CAP_OP_MOD_GENERAL_DEVICE);
 
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index a919dfb920ae..cc8ae860cd45 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -804,10 +804,12 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 reserved_at_150[0xa];
u8 log_max_ra_res_qp[0x6];
 
-   u8 pad_cap[0x1];
+   u8 end_pad[0x1];
u8 cc_query_allowed[0x1];
u8 cc_modify_allowed[0x1];
-   u8 reserved_at_163[0xd];
+   u8 start_pad[0x1];
+   u8 cache_line_128byte[0x1];
+   u8 reserved_at_163[0xb];
u8 gid_table_size[0x10];
 
u8 out_of_seq_cnt[0x1];
-- 
2.11.0