New RAW_PACKET QP type

The following patches add a new QP type named RAW_PACKET.

This type of QP is used in Ethernet environment and intended for creation of a whole packet, including L2 headers, from userspace. In order to prevent regular user from creating malicious packets, at the time of QP creation, kernel will check if the process has necessary permissions. This examination areis done in uverbs layer and is general for all low level drivers.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

The following patch add a new QP type named RAW_PACKET.

This type of QP is used in Ethernet environment and intended for creation of a whole packet, including L2 headers, from userspace.

Reserve a place for future XRC patch in order to be sure that OFED kernel ABI will not broken when XRC and RAW patches will be accepted to upstream kernel.

---
 drivers/infiniband/core/verbs.c |    4 ++--
 include/rdma/ib_verbs.h         |    3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

index af7a8b0..b04b419 100644
@@ -326,8 +326,8 @@ EXPORT_SYMBOL(ib_create_qp);
 
 static const struct {
 	int			valid;
-	enum ib_qp_attr_mask	req_param[IB_QPT_RAW_ETHERTYPE + 1];
-	enum ib_qp_attr_mask	opt_param[IB_QPT_RAW_ETHERTYPE + 1];
+	enum ib_qp_attr_mask	req_param[IB_QPT_RAW_PACKET + 1];
+	enum ib_qp_attr_mask	opt_param[IB_QPT_RAW_PACKET + 1];
 } qp_state_table[IB_QPS_ERR + 1][IB_QPS_ERR + 1] = {
 	[IB_QPS_RESET] = {
 		[IB_QPS_RESET] = { .valid = 1 },

index ecf098a..555165b 100644
@@ -562,7 +562,8 @@ enum ib_qp_type {
 	IB_QPT_UC,
 	IB_QPT_UD,
 	IB_QPT_RAW_IPV6,
-	IB_QPT_RAW_ETHERTYPE
+	IB_QPT_RAW_ETHERTYPE = 7,
+	IB_QPT_RAW_PACKET = 8
 };
 
 enum ib_qp_create_flags {

1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Check if user process has permission to create RAW_PACKET QP.

In order to prevent regular user from creating malicious packets, at the time of QP creation, kernel will check if the process has necessary permissions. This examination areis done in uverbs layer and is general for all low level drivers.

---
 drivers/infiniband/core/uverbs_cmd.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

index 6fcfbeb..87025fc 100644
@@ -1050,6 +1050,9 @@ ssize_t ib_uverbs_create_qp(struct ib_uverbs_file *file,
 	if (copy_from_user(&cmd, buf, sizeof cmd))
 		return -EFAULT;
 
+	if (cmd.qp_type == IB_QPT_RAW_PACKET && !capable(CAP_NET_RAW))
+		return -EPERM;
+
 	INIT_UDATA(&udata, buf + sizeof cmd,
 		   (unsigned long) cmd.response + sizeof resp,
 		   in_len - sizeof cmd, out_len - sizeof resp);

1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Added RAW_PACKET to ib_attach/detach calls

Add iWARP transport to attach/detach mcast. Differentiate between transport types when dealing with multicast.

---
 drivers/infiniband/core/verbs.c |   24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)

index b04b419..a053c0e 100644
@@ -903,9 +903,17 @@ int ib_attach_mcast(struct ib_qp *qp, union ib_gid *gid, u16 lid)
 {
 	if (!qp->device->attach_mcast)
 		return -ENOSYS;
-	if (gid->raw[0] != 0xff || qp->qp_type != IB_QPT_UD)
-		return -EINVAL;
 
+	switch (rdma_node_get_transport(qp->device->node_type)) {
+	case RDMA_TRANSPORT_IB:
+		if (gid->raw[0] != 0xff || qp->qp_type != IB_QPT_UD)
+			return -EINVAL;
+		break;
+	case RDMA_TRANSPORT_IWARP:
+		if (qp->qp_type != IB_QPT_RAW_PACKET)
+			return -EINVAL;
+		break;
+	}
 	return qp->device->attach_mcast(qp, gid, lid);
 }
 EXPORT_SYMBOL(ib_attach_mcast);

@@ -914,9 +922,17 @@ int ib_detach_mcast(struct ib_qp *qp, union ib_gid *gid, u16 lid)
 {
 	if (!qp->device->detach_mcast)
 		return -ENOSYS;
-	if (gid->raw[0] != 0xff || qp->qp_type != IB_QPT_UD)
-		return -EINVAL;
 
+	switch (rdma_node_get_transport(qp->device->node_type)) {
+	case RDMA_TRANSPORT_IB:
+		if (gid->raw[0] != 0xff || qp->qp_type != IB_QPT_UD)
+			return -EINVAL;
+		break;
+	case RDMA_TRANSPORT_IWARP:
+		if (qp->qp_type != IB_QPT_RAW_PACKET)
+			return -EINVAL;
+		break;
+	}
 	return qp->device->detach_mcast(qp, gid, lid);
 }
 EXPORT_SYMBOL(ib_detach_mcast);

1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RAW_FRAME seems like a better name to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Not that it matters much, but doesn't "FRAME" and "PACKET" mean the same thing?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I associate frame with L2 and packet with L3. Since the user is expected to provide the L2 header, frame seems clearer than packet. Then when someone wants to introduce the RAW_PACKET where the user only provides the L3 header, we still have something we can call it.

Or maybe we call this a LAYER2 QP..?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

The linux PF_PACKET interface comes to mind. It allows sending/receiving raw ethernet frames:

----
Packet sockets are used to receive or send raw packets at the
device
driver (OSI Layer 2) level. They allow the user to implement
protocol
modules in user space on top of the physical layer.
-----

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I don't have a strong preference on the name, but isn't PF_PACKET further qualified by the socket type to indicate if the user provides the L2 header or not? Maybe we just need that additional qualifier. --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Yea, you're correct.

Maybe we need some attributes that get passed in at qp create or qp modify ->RTS or something?

I'm working on similar code for Chelsio that will use these QPs. I do need additional attributes to be passed in. But I'm not nearly ready to propose the details yet.

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Will the TX flow require going into kernel space or will be fully offloaded?

Or.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

The RX/TX paths are kernel bypass unless the application wants to block for IO.

Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

As I understand, Ethernet frame contains preamble and delimiter in addition to the packet data and we construct only packet.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I think that RAW_PACKET is good compromise - RAW Ethertype comes from IB and PF_PACKET from Ethernet. But, since it intended to be used over Ethernet, I would leave names similar.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Is there anything different in this patch set compared to V1 of https://patchwork.kernel.org/patch/110153 or its just a repost?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

These look good to me.

Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

I've found small inaccuracies in the series and ask you not to apply it. I'll resend a newer version.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html