lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 20 Mar 2018 13:21:28 -0400
From:   Doug Ledford <dledford@...hat.com>
To:     David Ahern <dsahern@...il.com>, Leon Romanovsky <leon@...nel.org>,
        stephen@...workplumber.org
Cc:     Steve Wise <swise@...ngridcomputing.com>, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org
Subject: Re: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource
 tracking

On 3/16/2018 12:18 PM, David Ahern wrote:
> On 3/13/18 1:58 PM, Doug Ledford wrote:
>> On Tue, 2018-03-13 at 13:45 -0700, David Ahern wrote:
>>> On 3/13/18 1:32 AM, Leon Romanovsky wrote:
>>>> On Mon, Mar 12, 2018 at 10:53:03AM -0700, David Ahern wrote:
>>>>> On 3/12/18 8:16 AM, Steve Wise wrote:
>>>>>> Hey all,
>>>>>>
>>>>>> The kernel side of this series has been merged for rdma-next [1].  Let me
>>>>>> know if this iproute2 series can be merged, of if it needs more changes.
>>>>>>
>>>>>
>>>>> The problem is that iproute2 headers are synced to kernel headers from
>>>>> DaveM's tree (net-next mainly). I take it this series will not appear in
>>>>> Dave's tree until after a merge through Linus' tree. Correct?
>>>>
>>>> David,
>>>>
>>>> Technically, you are right, and we would like to ask you for an extra tweak
>>>> to the flow for the RDMAtool, because current scheme causes delays at least
>>>> cycle.
>>>>
>>>> Every RDMAtool's patchset which requires changes to headers is always
>>>> includes header patch, can you please accept those series and once you
>>>> are bringing new net-next headers from Linus, simply overwrite all our
>>>> headers?
>>>
>>> I did not follow the discussion back when this decision was made, so how
>>> did rdma tool end up in iproute2?
>>
>> It is modeled after the ip command, and for better or worse, the
>> iproute2 package has become the standard drop box for low level kernel
>> network configuring tools.  The RDMA subsystem may not be IP networking,
>> but it is still networking, so it seemed an appropriate fit.
> 
> why doesn't the rdma tree go through Dave then?
> 

Because it doesn't use the core network stack hardly at all.  It creates
netdevs when it needs to bridge the two stacks, but otherwise the RDMA
subsystem core is apart and unique from the network stack Dave manages.
When I said it was networking, I meant it literally.  The RDMA fabrics
are networks.  It wasn't meant to imply that they shared anything
substantial in common with the typical Ethernet/IP networking that is
the core of what Dave manages.



Download attachment "signature.asc" of type "application/pgp-signature" (899 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ