Re: [openib-general] Re: [iproute2] IPoIB link layer address bug

On Tue, Mar 21, 2006 at 03:56:17PM -0800, Stephen Hemminger wrote: Okay, but there are number of other places in iproute2 that call ll_addr_a2n() with ifr.ifr_hwaddr.sa_data. And that is 14 bytes. If you want to fix those it will be harder since it would increase the sizeof(struct sockaddr)

Re: [PATCH v2 07/11] IB/cm: Add network namespace support

On Tue, Apr 21, 2015 at 03:07:47PM +0300, Haggai Eran wrote: Namespace is needed for RoCE address resolution, in cases where the driver doesn't report the MAC as part of the ib_wc. This patch explicitly says it doesn't deal with RoCE, so why are we adding namespaces to support RoCE paths in

Re: [PATCH v2 02/11] IB/addr: Pass network namespace as a parameter

On Mon, Apr 20, 2015 at 12:03:33PM +0300, Haggai Eran wrote: +/** rdma_addr_find_smac_by_sgid() - Find the src MAC and VLAN ID for a src GID + * @sgid:Source GID to find the MAC and VLAN for. + * @smac:A buffer to contain the resulting MAC address. + * @vlan_id: Will contain the

Re: [PATCH v2 01/11] RDMA/CMA: Mark IPv4 addresses correctly when the listener is IPv6

On Mon, Apr 20, 2015 at 12:03:32PM +0300, Haggai Eran wrote: From: Yotam Kenneth yota...@mellanox.com When accepting a new connection with the listener being IPv6, the family of the new connection is set as IPv6. This causes cma_zero_addr function to return true on an non-zero address. As a

Re: [PATCH v2 07/11] IB/cm: Add network namespace support

On Mon, Apr 20, 2015 at 12:03:38PM +0300, Haggai Eran wrote: From: Guy Shapiro gu...@mellanox.com Add namespace support to the IB-CM layer. - Each CM-ID now has a network namespace it is associated with, assigned at creation. This namespace is used as needed during subsequent action on

Re: [PATCH v2 01/11] RDMA/CMA: Mark IPv4 addresses correctly when the listener is IPv6

On Mon, Apr 20, 2015 at 09:38:02PM +0300, Or Gerlitz wrote: On Mon, Apr 20, 2015 at 7:41 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Mon, Apr 20, 2015 at 12:03:32PM +0300, Haggai Eran wrote: From: Yotam Kenneth yota...@mellanox.com When accepting a new connection

Re: [PATCH linux-next 1/4] infiniband/ipoib: fix possible NULL pointer dereference in ipoib_get_iflink

On Wed, Apr 15, 2015 at 09:17:14AM +0300, Erez Shitrit wrote: + /* parent interface */ + if (!test_bit(IPOIB_FLAG_SUBINTERFACE, priv-flags)) + return dev-ifindex; + + /* child/vlan interface */ + if (!priv-parent) + return -1; Like was

Re: [PATCH net-next v2 1/4] cxgb4/iw_cxgb4/cxgb4i: remove duplicate definitions

On Wed, Apr 15, 2015 at 06:34:27PM +0530, Varun Prakash wrote: On Mon, Apr 13, 2015 at 10:38:08AM -0600, Jason Gunthorpe wrote: On Mon, Apr 13, 2015 at 07:34:23PM +0530, Varun Prakash wrote: define struct ulptx_idata in common header file t4_msg.h to remove duplicate definitions

Re: [PATCH V1 net-next] IB/ipoib: Fix ndo_get_iflink

ndo_get_iflink') Reported-by: Honggang Li ho...@redhat.com Signed-off-by: Erez Shitrit ere...@mellanox.com Signed-off-by: Honggang Li ho...@redhat.com Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com+ changes from V0: - fixed two typos in the change-log drivers/infiniband/ulp/ipoib

Re: [PATCH v4 for-next 05/12] IB/cm: Share listening CM IDs

On Tue, May 19, 2015 at 12:35:45PM -0600, Jason Gunthorpe wrote: On Sun, May 17, 2015 at 08:51:01AM +0300, Haggai Eran wrote: @@ -212,6 +212,8 @@ struct cm_id_private { spinlock_t lock;/* Do not acquire inside cm.lock */ struct completion comp; atomic_t refcount

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Wed, Jun 03, 2015 at 10:05:34PM +0300, Or Gerlitz wrote: Indeed the DHCP story isn't working there and to get DHCP work something has to be done. But this issue can't serve for blocking the existing UAPI and introduce regression to working systems. It is not DHCP that concerns me, it is

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Wed, Jun 03, 2015 at 11:07:37PM +0300, Or Gerlitz wrote: I'm mostly fine with it as an optional capability, similar to macvlan, I just don't see how to cleanly integrate it with RDMA CM and namespaces. And I don't see what RDMA CM is supposed to do when it hits this case. So, any

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Wed, Jun 03, 2015 at 11:07:37PM +0300, Or Gerlitz wrote: As Haggai wrote, if we let the using IP address thing to fly up, we have support for RDMA in containers using the RDMA-CM at IPoIB environments. This will let people test, use, experiment, fix, interact (and even production-it when

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Mon, Jun 08, 2015 at 10:52:34AM +0300, Haggai Eran wrote: On 04/06/2015 19:40, Jason Gunthorpe wrote: Discussion idea: Can we actually use the netstack to process the RDMA-CM packets? It looks like the netstack wants a skb to do this mid-layer work, so rdma-cm would have to synthesize

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Wed, Jun 03, 2015 at 01:03:01PM +0300, Haggai Eran wrote: Then I'm inclined to say that we should map for namespaces using device, port, guid/gid, pkey. And in this situation, since a unique guid/gid on any given pkey maps to a unique dhcp identifier and a unique ipv6 lladdr, this

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Thu, Jun 04, 2015 at 09:24:37AM +0300, Haggai Eran wrote: The l2/l3 distinction in ipvlan is also very interesting. The L3 mode solves some of the security type issues. What do you think Haggi? I think some issues ipvlan is trying to solve would also affect us using the alias GUIDs

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Thu, Jun 04, 2015 at 12:41:33PM +0300, Haggai Eran wrote: On 04/06/2015 00:45, Jason Gunthorpe wrote: I don't know if that is a good idea, an unstable SLAAC is not in spirit with the RFCs. The safest bet is to return error and disable SLAAC completely. Maybe this is a silly question

Re: [PATCH 08/11] IB/cma: Add net_dev and private data checks to RDMA CM

On Tue, Jun 16, 2015 at 08:26:26AM +0300, Haggai Eran wrote: On 15/06/2015 20:08, Jason Gunthorpe wrote: On Mon, Jun 15, 2015 at 11:47:13AM +0300, Haggai Eran wrote: Instead of relying on a the ib_cm module to check an incoming CM request's private data header, add these checks to the RDMA

Re: [PATCH 04/11] IB/cm: Expose DGID in SIDR request events

On Tue, Jun 16, 2015 at 02:25:07PM +0300, Haggai Eran wrote: But how is that going to work? How is the sender to know it should be sending a GRH with the CM message? If the admin wants to use SIDR with alias GIDs, they will need to configure the system to enable GRH for such GMPs. (This

Re: [PATCH 02/11] IB/ipoib: Return IPoIB devices matching connection parameters

On Mon, Jun 15, 2015 at 11:47:07AM +0300, Haggai Eran wrote: +/* Called with an RCU read lock taken */ Add _rcu to the name? That is the standard convention. +/* returns an IPoIB netdev on top a given ipoib device matching a pkey_index + * and address, if one exists. */ +static struct

Re: [PATCH 08/11] IB/cma: Add net_dev and private data checks to RDMA CM

On Mon, Jun 15, 2015 at 11:47:13AM +0300, Haggai Eran wrote: Instead of relying on a the ib_cm module to check an incoming CM request's private data header, add these checks to the RDMA CM module. This allows a following patch to to clean up the ib_cm interface and remove the code that looks

Re: [PATCH 04/11] IB/cm: Expose DGID in SIDR request events

On Mon, Jun 15, 2015 at 09:32:53PM +, Hefty, Sean wrote: drivers/infiniband/core/cm.c | 7 +++ include/rdma/ib_cm.h | 2 ++ 2 files changed, 9 insertions(+) diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index c5f5f89e274a..46f99ec4080a

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Thu, May 28, 2015 at 07:21:11PM +0300, Or Gerlitz wrote: Anything else except for that (you said reworking of the network scripts and NetworkManager assumptions to make it work)?? IPv6 becomes very broken, child interfaces will generate the same IPv6 addreses for radv and link local

Re: [PATCH] sctp: Fix mangled IPv4 addresses on a IPv6 listening socket

On Wed, May 27, 2015 at 10:11:22AM +, David Laight wrote: In any case it looks like I can escape by turning off SCTP_I_WANT_MAPPED_V4_ADDR for kernels 3.17 through 4.0. Just be aware that option is unusable on kernels without 299ee. I fixed everything wrong I saw, but that doesn't mean it

Re: [PATCH] sctp: Fix mangled IPv4 addresses on a IPv6 listening socket

On Wed, May 27, 2015 at 04:41:18PM +, David Laight wrote: The code will be sleeping in kernel_accept() and later calls kernel_getpeername(). The code is used for both TCP and SCTP and this part is common (using the TCP semantics). getpeername uses a different flow, it calls into

Re: [PATCH] sctp: Fix mangled IPv4 addresses on a IPv6 listening socket

On Wed, May 27, 2015 at 04:16:44PM +, David Laight wrote: From: Jason Gunthorpe Sent: 27 May 2015 16:32 On Wed, May 27, 2015 at 10:11:22AM +, David Laight wrote: In any case it looks like I can escape by turning off SCTP_I_WANT_MAPPED_V4_ADDR for kernels 3.17 through 4.0

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Thu, May 28, 2015 at 04:22:36PM +0300, Haggai Eran wrote: wouldn't care if they share the QP number namespace, etc. RDMA CM ports are different because they are chosen by the applications, but they map directly to the network namespace, so they don't require their own namespace. Different

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

On Thu, May 28, 2015 at 02:51:51PM +0300, Haggai Eran wrote: But RDMA CM doesn't provide the QPN. So when RDMA CM searches the netdevs for an address it cannot *uniquely* map to a IPoIB interface. This is technically true, but if someone configures their system that way, they will also

Re: [PATCH] rtnetlink: Actually use the policy for the IFLA_VF_INFO

On Thu, Jul 02, 2015 at 10:34:54AM +0200, Daniel Borkmann wrote: So, commit c02db8c6290b moved it into a nested attribute (IFLA_VF_INFO) where we indeed don't do further validation. Imho, we should pass the parsed attribute table from nla_parse_nested() down into do_setvfinfo(), something like

Re: [PATCH] rtnetlink: Actually use the policy for the IFLA_VF_INFO

On Wed, Jul 01, 2015 at 11:36:15AM +0200, Daniel Borkmann wrote: Hi Jason, On 07/01/2015 12:52 AM, Jason Gunthorpe wrote: It turns out the policy was defined but never actually checked, so lets check it. Fixes: ebc08a6f47ee (rtnetlink: Add VF config code to rtnetlink) I would argue

Re: [PATCH v4 for-next 04/12] IB/ipoib: Return IPoIB devices matching connection parameters

On Thu, May 21, 2015 at 08:33:53AM +0300, Haggai Eran wrote: To create a new child interface on the default P_Key, its possible to use iproute: # ip link add link ib0 name ib0.1 type ipoib Uh.. A key invariant of the IP stack is that is it possible to uniquely identify the ingress device.

Re: [PATCH v4 for-next 05/12] IB/cm: Share listening CM IDs

On Thu, May 21, 2015 at 11:08:31AM +0300, Haggai Eran wrote: The more I look at this, the more I think it is sketchy. Don't try and merge sharecount and refcount together, I'm not sure what you mean here. The way I was thinking about it was that sharecount = num of rdma_cm_ids sharing this

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Tue, May 26, 2015 at 01:46:36PM -0400, Doug Ledford wrote: Remember, this isn't RDMA namespaces, this is netdev namespace support for RDMA-CM - very different things. That was the point of my email. This is a very myopic view of the feature. It *should* at least have an idea of these

[PATCH] sctp: Fix mangled IPv4 addresses on a IPv6 listening socket

is wrong. Fixes: 299ee123e198 (sctp: Fixup v4mapped behaviour to comply with Sock API) Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com --- include/net/sctp/sctp.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) This bugfix should be a candidate for -stable diff --git

Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

On Tue, May 26, 2015 at 09:34:40AM -0400, Doug Ledford wrote: This is a core feature more than anything else. Namespaces for RDMA devices is not unique to IB or RoCE in any way. Yet no thought has been given to how this will work universally across all of the RDMA capable I think if Haggi

[PATCH] rtnetlink: Actually use the policy for the IFLA_VF_INFO

It turns out the policy was defined but never actually checked, so lets check it. Fixes: ebc08a6f47ee (rtnetlink: Add VF config code to rtnetlink) Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com --- net/core/rtnetlink.c | 13 + 1 file changed, 13 insertions(+) DaveM

Re: Re: [PATCH for-next V7 00/10] Move RoCE GID management to IB/Core

In many respects, I expect the ib_unregister_device() call to mirror the error unwind found in the register call with the modifications for dealing with a device that was actually live. Yes, it should look like that, I also noticed there were ordering problems in this area. and we probably

Re: [PATCH for-next V7 00/10] Move RoCE GID management to IB/Core

On Fri, Jul 31, 2015 at 08:50:24AM -0400, Doug Ledford wrote: So... are we ready to go with V7 upstream? Yes. I've already pulled it in. You are taking the netdev stuff without an ack from netdev?? I've been too busy too look at v7, but a quick check of the 'move the cache into core code

Re: [PATCH for-next V7 00/10] Move RoCE GID management to IB/Core

On Fri, Jul 31, 2015 at 01:41:39PM -0400, Doug Ledford wrote: Please be more specific here. What are you objecting to? Are you objecting to a flush_workqueue from a release() context? Because I don't see anything in the kref documentation or the kref implementation that prevents or

Re: [PATCH for-next V7 00/10] Move RoCE GID management to IB/Core

On Sat, Aug 01, 2015 at 12:24:23AM +0300, Or Gerlitz wrote: addressed in incremental patch, as Doug suggested. Jason, it's wrong to send developers again and again to fix things which were perfect in Vn-1 but also not being covered by reviewers on Vn-1, at some point the reviewer can't load

Re: [PATCH v1 08/12] IB/cma: Add net_dev and private data checks to RDMA CM

On Wed, Jul 15, 2015 at 01:57:48PM +0300, Haggai Eran wrote: On 13/07/2015 21:14, Jason Gunthorpe wrote: On Mon, Jun 22, 2015 at 03:42:37PM +0300, Haggai Eran wrote: + switch (ib_event-event) { + case IB_CM_REQ_RECEIVED: + req-device = req_param-listen_id-device

Re: [PATCH v1 08/12] IB/cma: Add net_dev and private data checks to RDMA CM

On Wed, Jul 15, 2015 at 08:27:06PM +, Liran Liss wrote: If you want to restrict a container to a specific set of pkeys, use cgroups. Ideally yes, but in the absence of a cgroup the set of pkeys assigned to the container via ipoib is a reasonable alternate. This would apply both to CM MADs

Re: [PATCH v1 08/12] IB/cma: Add net_dev and private data checks to RDMA CM

On Thu, Jul 16, 2015 at 12:01:55PM +, Liran Liss wrote: - Name space lookup is done based on BTH.pkey, private_data.IP, and optionally GRH.DGID (if present, for extra validation) Just changing the pkey to BTH.pkey would be fine by me. Using GRH.DGID if available instead of the primary

Re: [PATCH v1 08/12] IB/cma: Add net_dev and private data checks to RDMA CM

On Mon, Jun 22, 2015 at 03:42:37PM +0300, Haggai Eran wrote: + switch (ib_event-event) { + case IB_CM_REQ_RECEIVED: + req-device = req_param-listen_id-device; + req-port = req_param-port; + req-local_gid = req_param-primary_path-sgid; +

Re: [PATCH v1 05/12] IB/cm: Share listening CM IDs

problems with this. Sean said he was happy with the idea right? Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com Jason -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH v1 11/12] IB/cma: Share ib_cm_ids between rdma_cm_ids

On Mon, Jun 22, 2015 at 03:42:40PM +0300, Haggai Eran wrote: Use ib_cm_id_create_and_listen to create listening IB CM IDs or share ^^^ Is that the wrong name? ib_cm_insert_listen perhaps? I think I've looked at the details in this series I was concerned about, Sean

Re: [PATCH v1 05/12] IB/cm: Share listening CM IDs

On Tue, Jul 14, 2015 at 11:45:15AM +0300, Haggai Eran wrote: Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com Thanks. Can I add it with the modifications above? Yep Jason -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord

Re: [PATCH v1 01/12] IB/core: pass client data to remove() callbacks

On Mon, Jun 22, 2015 at 03:42:30PM +0300, Haggai Eran wrote: An ib_client callback that is called with the lists_rwsem locked only for read is protected from changes to the IB client lists, but not from ib_unregister_device() freeing its client data. This is because ib_unregister_device() will

Re: [PATCH v1 02/12] IB/core: Find the network device matching connection parameters

, + u16 pkey, const union ib_gid *gid, + const struct sockaddr *addr); I feel like this has been repated a few times now, but kdocs should be with the function body, not in the header. Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com

Re: [PATCH v1 01/12] IB/core: pass client data to remove() callbacks

On Wed, Jul 08, 2015 at 02:29:10PM -0600, Jason Gunthorpe wrote: On Mon, Jun 22, 2015 at 03:42:30PM +0300, Haggai Eran wrote: An ib_client callback that is called with the lists_rwsem locked only for read is protected from changes to the IB client lists, but not from ib_unregister_device

Re: [PATCH v1 03/12] IB/ipoib: Return IPoIB devices matching connection parameters

On Mon, Jun 22, 2015 at 03:42:32PM +0300, Haggai Eran wrote: + if (net_dev) { + ipoib_warn(priv, matching net_dev found: %s\n, +net_dev-name); Is that a debug print? + default: + dev_warn(dev-dev, duplicate IP

Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%

On Wed, Jun 22, 2016 at 11:23:59AM -0700, Joe Perches wrote: > The output changes now do not include line #, but do include the > function offset. I've been using a technique like this in some code with good results: struct source_location { const char *file; const char *func; const

Re: [PATCH for-next 01/10] net/core: Add support for configuring VF GUIDs

On Tue, Mar 01, 2016 at 07:49:51PM +0200, Eli Cohen wrote: > On Tue, Mar 01, 2016 at 10:37:51AM -0700, Jason Gunthorpe wrote: > > > + return handle_infiniband_guid(dev, , IFLA_VF_IB_PORT_GUID); > > > > But is this emulation really necessary? It seems dangerous and > &

Re: [PATCH for-next 01/10] net/core: Add support for configuring VF GUIDs

On Tue, Mar 01, 2016 at 06:52:14PM +0200, Eli Cohen wrote: > Add two new NLAs to support configuration of Infiniband node or port > GUIDs. New applications can choose to use this interface to configure > GUIDs with iproute2 with commands such as: > > ip link set dev ib0 vf 0 node_guid

Re: [PATCH for-next V1 1/2] net/mlx5: Fix mlx5 ifc cmd_hca_cap bad offsets

On Wed, Apr 13, 2016 at 07:11:03PM +0300, Saeed Mahameed wrote: > Fixes: b084590e ("net/mlx5_core: Introduce access function to read > internal timer ") > Fixes: b4ff3a36d3e4 ("net/mlx5: Use offset based reserved field names in the > IFC header file") Are you sure those are right?

Re: [patch v2] net/mlx5: missing error code in esw_create_offloads_fdb_table()

On Wed, Jul 13, 2016 at 02:48:44PM +0300, Dan Carpenter wrote: > We accidentally return success when we had intended to return an error > code. > > Fixes: 69697b6e2086 ('net/mlx5: E-Switch, Add support for the sriov offloads > mode') > Signed-off-by: Dan Carpenter >

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 08, 2016 at 07:18:11AM -0700, Roland Dreier wrote: > On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe > <jguntho...@obsidianresearch.com> wrote: > > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > > > A first blush that would seem t

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 07, 2016 at 03:01:40PM -0700, Roland Dreier wrote: > The reason we moved to the cb storage is that in the past, trying to > hide some data in the actual skb buffer that we don't actually send We have neighbour_priv, and ndo_neigh_construct/destruct now .. A first blush that would

Re: [RFC v3 02/11] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) interface

On Tue, Feb 07, 2017 at 12:23:01PM -0800, Vishwanathapura, Niranjana wrote: > Add rdma netdev interface to ib device structure allowing rdma netdev > devices to be allocated by ib clients. > Define HFI VNIC interface between hardware independent VNIC > functionality and the hardware dependent VNIC

Re: [RFC v3 02/11] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) interface

On Wed, Feb 08, 2017 at 08:54:37AM +0200, Leon Romanovsky wrote: > On Tue, Feb 07, 2017 at 02:19:01PM -0700, Jason Gunthorpe wrote: > > On Tue, Feb 07, 2017 at 12:23:01PM -0800, Vishwanathapura, Niranjana wrote: > > > Add rdma netdev interface to ib device structure al

Re: [RFC v3 00/11] HFI Virtual Network Interface Controller (VNIC)

On Tue, Feb 07, 2017 at 04:54:16PM -0800, Vishwanathapura, Niranjana wrote: > On Tue, Feb 07, 2017 at 09:58:50PM +, Bart Van Assche wrote: > >On Tue, 2017-02-07 at 21:44 +, Hefty, Sean wrote: > >>This is Ethernet - not IP - encapsulation over a non-InfiniBand > >>device/protocol. > > >

Re: [RFC v3 02/11] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) interface

On Tue, Feb 07, 2017 at 02:06:30PM -0800, Vishwanathapura, Niranjana wrote: > >>IB_DEVICE_RAW_SCATTER_FCS = (1ULL << 34), > >>+ IB_DEVICE_RDMA_NETDEV_HFI_VNIC = (1ULL << 35), > > > >What is this called HFI_VNIC anyhow? Shouldn't this be OPA_VNIC? There > >is nothing

Re: [RFC v3 00/11] HFI Virtual Network Interface Controller (VNIC)

On Sun, Feb 12, 2017 at 01:26:35PM +, Liran Liss wrote: > > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > > ow...@vger.kernel.org] On Behalf Of Vishwanathapura, Niranjana > > > > > ChangeLog: > > = > > v2 => v3: > > a) Introduce and adopt generic RDMA netdev interface

Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)

On Wed, Jan 18, 2017 at 07:43:54AM +0200, Leon Romanovsky wrote: > > I have started working on porting hfi_vnic as per this new interface. > > I will post RFC v3 later. > > Posting the interface definition early for comments. > > I wonder how many people will comment it without seeing usage

Re: [RFC] RESEND - rdmatool - tool for RDMA users

On Wed, Jan 18, 2017 at 07:50:26PM +0200, Or Gerlitz wrote: > On Wed, Jan 18, 2017 at 7:33 PM, Leon Romanovsky wrote: > > On Wed, Jan 18, 2017 at 06:48:21PM +0200, Or Gerlitz wrote: > >> On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog > >> wrote: > > >>> As of today,

Re: [RFC] RESEND - rdmatool - tool for RDMA users

On Thu, Jan 19, 2017 at 10:06:12PM +, Bart Van Assche wrote: > On Thu, 2017-01-19 at 11:03 -0700, Jason Gunthorpe wrote: > > sysfs is unpopular because the 'one value per file' dogma is laregly > > unsuitable for complex mulit-value atomic changes which are common in > >

Re: [RFC] RESEND - rdmatool - tool for RDMA users

On Thu, Jan 19, 2017 at 08:33:26AM +0200, Leon Romanovsky wrote: > On Wed, Jan 18, 2017 at 01:45:14PM -0800, Bart Van Assche wrote: > > On 01/18/2017 10:31 AM, Jason Gunthorpe wrote: > > > I think it depends on what this tool is supposed to cover, but based > > > on the

Re: [RFC 00/11] QLogic RDMA Driver (qedr) RFC

On Tue, Sep 13, 2016 at 08:44:06AM +, Ram Amrani wrote: > Hi Jason, > I see that "include/uapi/rdma" contains API that is common. It is intended to contain *all* the uapi. > The qedr_user.h, that I assume you are referring to, is a qedr specific API. > For example, we issue the

Re: [PATCH v4 00/16] Add Paravirtual RDMA Driver

On Mon, Sep 12, 2016 at 10:43:00PM +, Adit Ranadive wrote: > On Mon, Sep 12, 2016 at 11:03:39 -0700, Jason Gunthorpe wrote: > > On Sun, Sep 11, 2016 at 09:49:10PM -0700, Adit Ranadive wrote: > > > [2] Libpvrdma User-level library - > > > http://git.openfabrics.

Re: [RFC 00/11] QLogic RDMA Driver (qedr) RFC

On Wed, Sep 14, 2016 at 02:44:47PM +, Amrani, Ram wrote: > > Anything that is used with copy_to/from_user, ib_copy_to/from_udata, > > etc, etc must be in a include/uapi header. > > > > Any constant you might want to copy into your userspace provider must > > be in include/uapi. > > > I

Re: [PATCH v4 00/16] Add Paravirtual RDMA Driver

On Wed, Sep 14, 2016 at 07:44:45PM +, Adit Ranadive wrote: > On Wed, Sep 14, 2016 at 10:37:00 -0700, Jason Gunthorpe wrote: > > We desire to use this as the vehical for the userspace included with the 4.9 > > kernel. > > > > I anticipate the tree will be running by

Re: [PATCH v4 00/16] Add Paravirtual RDMA Driver

On Sun, Sep 11, 2016 at 09:49:10PM -0700, Adit Ranadive wrote: > [2] Libpvrdma User-level library - > http://git.openfabrics.org/?p=~aditr/libpvrdma.git;a=summary You will probably find that rdma-plumbing will be the best way to get your userspace component into the distributors.

Re: [PATCH v4 16/16] MAINTAINERS: Update for PVRDMA driver

On Sun, Sep 11, 2016 at 09:49:26PM -0700, Adit Ranadive wrote: > Add maintainer info for the PVRDMA driver. You can probably squash the last three patches. .. and fix the __u32 stuff throughout the entire driver please. Jason

Re: [PATCH v4 03/16] IB/pvrdma: Add virtual device RDMA structures

On Sun, Sep 11, 2016 at 09:49:13PM -0700, Adit Ranadive wrote: > + __u8raw[16]; > + struct { > + __be64 subnet_prefix; > + __be64 interface_id; > + } global; If this is not a userspace header do not use the __ varients.. Jason

Re: [PATCH v4 02/16] IB/pvrdma: Add user-level shared functions

On Sun, Sep 11, 2016 at 09:49:12PM -0700, Adit Ranadive wrote: > We share some common structures with the user-level driver. This patch > adds those structures and shared functions to traverse the QP/CQ rings. > create mode 100644 drivers/infiniband/hw/pvrdma/pvrdma_uapi.h > create mode 100644

Re: [RFC 00/11] QLogic RDMA Driver (qedr) RFC

On Mon, Sep 12, 2016 at 07:07:34PM +0300, Ram Amrani wrote: > drivers/infiniband/hw/qedr/main.c | 907 ++ > drivers/infiniband/hw/qedr/qedr.h | 494 > drivers/infiniband/hw/qedr/qedr_cm.c | 626 + > drivers/infiniband/hw/qedr/qedr_cm.h

Re: [PATCH v4 00/16] Add Paravirtual RDMA Driver

On Mon, Sep 12, 2016 at 10:43:00PM +, Adit Ranadive wrote: > On Mon, Sep 12, 2016 at 11:03:39 -0700, Jason Gunthorpe wrote: > > On Sun, Sep 11, 2016 at 09:49:10PM -0700, Adit Ranadive wrote: > > > [2] Libpvrdma User-level library - > > > http://git.openfabrics.

Re: [PATCH v4 00/16] Add Paravirtual RDMA Driver

On Wed, Sep 14, 2016 at 10:20:22PM +, Woodruff, Robert J wrote: > >this new scheme works with >kernel.org 4.8, then it is possible > >that it could go into that OFED-4.8 Release, but again, we are > >still looking at the new scheme and evaluating how it affects >the > >community OFED. > >

Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver

On Sun, Sep 25, 2016 at 10:25:12PM -0700, Adit Ranadive wrote: > > As Jason said, you need a very good reason to split and create number of > > files per-driver in UAPI folder. > > I can move the pvrdma-uapi.h back to the pvrdma driver folder. Just don't copy any of the content into your user

Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver

On Mon, Sep 26, 2016 at 01:40:10PM -0700, Adit Ranadive wrote: > Wouldnt they be some overlap between the user-space and kernel driver? Or is > it expected that the common structures (even device specific ones) be moved to > the ABI file? Yes, even device specific structures must be in the abi

Re: [RFC v2 06/12] qedr: Add support for QP verbs

On Tue, Sep 20, 2016 at 01:35:58PM +0300, Ram Amrani wrote: > +++ b/include/uapi/rdma/providers/qedr-abi.h > @@ -43,4 +43,39 @@ struct qedr_create_cq_uresp { > u16 icid; > }; Ugh, each patch keeps adding to this? > +struct qedr_create_qp_ureq { > + u32 qp_handle_hi; > + u32

Re: [RFC v2 04/12] qedr: Add support for user context verbs

On Tue, Sep 20, 2016 at 01:35:56PM +0300, Ram Amrani wrote: > +++ b/include/uapi/rdma/providers/qedr-abi.h > @@ -0,0 +1,27 @@ > +/* QLogic qed NIC Driver > + * Copyright (c) 2015 QLogic Corporation > + * > + * This software is available under the terms of the GNU General Public > License > + *

Re: [RFC v2 06/12] qedr: Add support for QP verbs

On Wed, Sep 21, 2016 at 02:23:46PM +, Amrani, Ram wrote: > > Ugh, each patch keeps adding to this? > > The logic in the patch series is to have each patch contain only > what is necessary for the specific functionality it adds. This made > it harder on us to prepare but, IMHO, easier for the

Re: [PATCH v4 00/16] Add Paravirtual RDMA Driver

On Wed, Sep 14, 2016 at 04:59:10PM -0600, Jason Gunthorpe wrote: > > package follows that licensing model for accepting any new code into > > that combined repo ? > > As with the kernel we'd discourage 're-licensing' existing files. > > However, since this is not a OF

[PATCH] net: mv643xx_eth: Fetch the phy connection type from DT

The MAC is capable of RGMII mode and that is probably a more typical connection type than GMII today (eg it is used by Marvell Reference designs for several SOCs). Let DT users specify the standard phy-connection-type = "rgmii-id"; On a phy node. Signed-off-by: Jason Gunthorp

[PATCH] uapi: Fix userspace compilation of ip_tables.h/ip6_tables.h in C++ mode

conversion from 'void*' to 'xt_entry_target*' Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> --- include/uapi/linux/netfilter_ipv4/ip_tables.h | 2 +- include/uapi/linux/netfilter_ipv6/ip6_tables.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/includ

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Thu, Nov 24, 2016 at 06:13:50PM -0800, Vishwanathapura, Niranjana wrote: > In order to be truely device independent the hfi_vnic ULP should not depend > on a device exported symbol. Instead device should register its functions > with the ULP. Hence the approaches a) and b). It is not device

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Mon, Nov 21, 2016 at 01:30:17PM -0800, Vishwanathapura, Niranjana wrote: > On Sat, Nov 19, 2016 at 12:04:45PM -0700, Jason Gunthorpe wrote: > >On Fri, Nov 18, 2016 at 02:42:10PM -0800, Vishwanathapura, Niranjana wrote: > >>+HFI-VNIC DRIVER > >>+M: Dennis D

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Mon, Nov 21, 2016 at 03:26:29PM -0800, Vishwanathapura, Niranjana wrote: > I did not see any example IB mad agent outside drivers/inifiniband > folder. You can be the first. > I did see some netdev drivers outside the net/ folder (like ipoib and > drivers/infiniband/hw/nes/). It is very

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Mon, Nov 21, 2016 at 05:53:04PM -0800, Vishwanathapura, Niranjana wrote: > There are many example drivers in kernel which are using bus_register() in > an initcall. There really are not, certainly not in major subsystems. > We could add a custom Interface between HFI1 driver and hfi_vnic

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Tue, Nov 22, 2016 at 07:05:05PM -0500, ira.weiny wrote: > On Tue, Nov 22, 2016 at 10:04:07AM -0700, Jason Gunthorpe wrote: > > On Mon, Nov 21, 2016 at 05:53:04PM -0800, Vishwanathapura, Niranjana wrote: > > > There are many example drivers in kernel which are

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Wed, Nov 23, 2016 at 04:08:25PM -0800, Vishwanathapura, Niranjana wrote: > In order to pass the hfi function pointers to the hfi_vnic ULP, I can, > a) Have hfi_vnic ULP define an interface API for hfi1 driver to call to > register its callback (as you pointed). Unfortunately there will be a

Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver

On Fri, Nov 18, 2016 at 02:42:10PM -0800, Vishwanathapura, Niranjana wrote: > +HFI-VNIC DRIVER > +M: Dennis Dalessandro > +M: Niranjana Vishwanathapura > +L: linux-r...@vger.kernel.org > +S: Supported > +F:

Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header

On Tue, Oct 11, 2016 at 07:15:44PM +0200, Paolo Abeni wrote: > Also the connected mode maximum mtu is reduced by 16 bytes to > cope with the increased hard header len. Changing the MTU is going to cause annoying interop problems, can you avoid this? Jason

Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header

On Tue, Oct 11, 2016 at 07:37:32PM +0200, Paolo Abeni wrote: > On Tue, 2016-10-11 at 11:32 -0600, Jason Gunthorpe wrote: > > On Tue, Oct 11, 2016 at 07:15:44PM +0200, Paolo Abeni wrote: > > > > > Also the connected mode maximum mtu is reduced by 16 bytes to > >

Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header

On Tue, Oct 11, 2016 at 01:41:56PM -0400, Doug Ledford wrote: > declare the header. The problem then became that the sg setup is such > that we are limited to 16 4k pages for the sg array, so that header had > to come out of the 64k maximum mtu. Oh, that clarifies things.. Hum, so various

Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header

On Tue, Oct 11, 2016 at 08:10:07PM +0200, Paolo Abeni wrote: > The first s/g fragment (the head buffer) is not allocated with the page > allocator, so perhaps there is some not too difficult/costly way out of > this. Keep in mind, there is nothing magic about the 16 SGL limit, other than we know

Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header

On Tue, Oct 11, 2016 at 02:17:51PM -0400, Doug Ledford wrote: > Well, not exactly. Even if we put 65520 into the scripts, the kernel > will silently drop it down to 65504. It actually won't require anyone > change anything, they just won't get the full value. I experimented > with this in the

Re: [RFC v2 03/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) netdev

On Wed, Dec 14, 2016 at 11:59:35PM -0800, Vishwanathapura, Niranjana wrote: > +/** > + * union hfi_vnic_bypass_hdr - VNIC bypass header > + * @slid: source lid > + * @length: length of packet > + * @becn: backward explicit congestion notification > + * @dlid: destination lid > + * @sc: service

Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)

On Wed, Dec 14, 2016 at 11:59:32PM -0800, Vishwanathapura, Niranjana wrote: > create mode 100644 drivers/infiniband/sw/intel/hfi_vnic/Kconfig > create mode 100644 drivers/infiniband/sw/intel/hfi_vnic/Makefile Stil NAK on these paths, I already explained why 'sw' is totally unsuitable. Put it in

  1   2   3   >