On 5/27/2020 5:46 AM, Max Gurtovoy wrote:
Use FRWR method to register memory by default and remove the ancient and
unsafe FMR method.
Signed-off-by: Max Gurtovoy
See the expected failures.
Tested-by: Dennis Dalessandro
Acked-by: Dennis Dalessandro
On 9/28/2019 1:55 AM, Leon Romanovsky wrote:
On Fri, Sep 27, 2019 at 04:17:15PM -0400, Doug Ledford wrote:
On Thu, 2019-09-26 at 21:55 +0200, gre...@linuxfoundation.org wrote:
On Thu, Sep 26, 2019 at 07:49:44PM +, Saleem, Shiraz wrote:
Subject: Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as dep
ime in pcpu_alloc_area(), but it
might be due to constantly breaking the hint as an immediate guess.
>
> Hi Vlad
>
> I guess this is more a question for per-cpu allocator experts / maintainers ?
>
> 16-bytes alignment for 16-bytes objects sound quite reasonable [1]
>
The alignment request seems reasonable. But as Tejun mentioned in a
reply to this, the overhead of forced alignment would be both in percpu
memory itself and in allocation time due to the stricter requirement.
Thanks,
Dennis
On 1/18/19 12:14 PM, Arnd Bergmann wrote:
On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote:
On 1/18/19 11:18 AM, Arnd Bergmann wrote:
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns
ource idea elsewhere.
Dennis Clarke
On 11/18/2018 6:05 AM, Leon Romanovsky wrote:
On Fri, Nov 16, 2018 at 08:10:35PM +, Ruhl, Michael J wrote:
-Original Message-
From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
ow...@vger.kernel.org] On Behalf Of Leon Romanovsky
Sent: Sunday, November 4, 2018 2:11 PM
To: Davi
I am in the military unit here in Afghanistan, we have some amount of funds
that we want to move out of the country. My partners and I need a good partner
someone we can trust. It is risk free and legal. Reply to this email:
hornbeckmajordennis...@gmail.com
Regards,Major Dennis Hornbeck.
On Mon, Feb 12, 2018 at 06:00:13PM +0100, Daniel Borkmann wrote:
>
> [ +Dennis, +Tejun ]
>
> Looks like we're stuck in percpu allocator with key/value size of 4 bytes
> each and large number of entries (max_entries) in the reproducer in above
> link.
>
> Cou
On Tue, Feb 13, 2018 at 09:49:27AM -0800, Eric Dumazet wrote:
> On Tue, 2018-02-13 at 11:34 -0600, Dennis Zhou wrote:
> > Hi Eric,
> >
> > On Tue, Feb 13, 2018 at 05:35:26AM -0800, Eric Dumazet wrote:
> > >
> > > Also I would consider using this fix as I
pages. I believe adding __GFP_NORETRY on the
workqueue path as Tejun mentioned above would help with warnings as
well, but not if they are caused by the allocation path.
Thanks,
Dennis
the minimum allocation size
with the unit size? It seems weird to arbitrate the maximum allocation
size given a lower bound on the unit size.
Thanks,
Dennis
On 7/3/2017 2:28 AM, Leon Romanovsky wrote:
From: Leon Romanovsky
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/nldev.c | 3 +++
include/uapi/rdma/rdma_netlink.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/cor
On 7/3/2017 2:28 AM, Leon Romanovsky wrote:
From: Leon Romanovsky
According to the IB specification, the LID and SM_LID
are 16-bit wide, but to support OmniPath users, export
it as 32-bit value from the beginning.
Signed-off-by: Leon Romanovsky
---
Reviewed-by: Dennis Dalessandro
Reviewed-by: Dennis Dalessandro
On 5/26/2017 12:35 PM, Saeed Mahameed wrote:
On Fri, May 26, 2017 at 3:56 PM, Dennis Dalessandro
wrote:
On 5/23/2017 7:44 AM, Saeed Mahameed wrote:
From: Tariq Toukan
Remove date and bump version for mlx5_core driver.
Signed-off-by: Tariq Toukan
Signed-off-by: Saeed Mahameed
So I
On 5/23/2017 7:44 AM, Saeed Mahameed wrote:
From: Tariq Toukan
Remove date and bump version for mlx5_core driver.
Signed-off-by: Tariq Toukan
Signed-off-by: Saeed Mahameed
So I just complained about the bnxt_re doing this. I guess I need to
raise a flag here too. Now to be clear I'm not a
On 05/04/2017 03:42 PM, Leon Romanovsky wrote:
On Thu, May 04, 2017 at 03:26:13PM -0400, Dennis Dalessandro wrote:
On 05/04/2017 02:45 PM, Leon Romanovsky wrote:
On Thu, May 04, 2017 at 06:30:27PM +, Bart Van Assche wrote:
On Thu, 2017-05-04 at 21:25 +0300, Leon Romanovsky wrote:
On Thu
On 05/04/2017 02:45 PM, Leon Romanovsky wrote:
On Thu, May 04, 2017 at 06:30:27PM +, Bart Van Assche wrote:
On Thu, 2017-05-04 at 21:25 +0300, Leon Romanovsky wrote:
On Thu, May 04, 2017 at 06:10:54PM +, Bart Van Assche wrote:
On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:
On 04/24/2017 10:35 AM, Christoph Hellwig wrote:
On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote:
Tested-by: Jakub Byczkowski
Are you (and Doug) ok with queueing this up in the PCI tree?
We are fine however Doug wants to handle it.
-Denny
My goal is to run some code before actual packets begin running in the IPSec
tunnel. For this, I am thinking of running a callback at the time of an XFRM
ESP tunnel creation, where tunnel IPs and the SPI will be known. Is there a
standard way of achieving this? If I'm not mistaken, registering f
> I have been reported 400 Mbps in a direction and 800 Mbps in the opposite
Speed of my dreams...
> If you are working from disk, the traffic will cross the pci bus twice.
> Expect something in the 40~60 Mbyte/s range. You could play with the mtu
> but I do not suggest it with an "old" kernel.
Hi!
> You are optimistic :o)
That´s a good starting point, I think - otherwise I would have thrown my
Equipment out of a window many times already ;)
> I can get a fine 100Mb/s with this equipment + poor cables (a few tens of
> meters + same path as the power distribution). With this setup, neg
Hi!
> > I am trying to build up a gigabit network with the following equipment
> > (all from Netgear):
>
> Same config here.
So if you are using exactly the same equipment, I think that only two points
can cause the problem:
1. One or more devices I am using are not working correctly. What I am
23 matches
Mail list logo
