[ewg] [PATCH] iWARP Multicast Acceleration description - nes_release_notes.txt update

[Walukiewicz, Miroslaw]

docs/nes: Add description of iWARP Multicast Acceleration

The document describes a usage model of the iWARP Multicast Acceleration

Signed-off-by: Mirek Walukiewicz <miroslaw.walukiewicz at intel.com>
---
diff --git a/nes_release_notes.txt b/nes_release_notes.txt
index 6386c54..b23abf3 100644
--- a/nes_release_notes.txt
+++ b/nes_release_notes.txt
@@ -269,5 +269,66 @@ Example mpirun command line:
            -mca btl_openib_flags 2
            /usr/mpi/gcc/openmpi-1.4.1/tests/IMB-3.2/IMB-MPI1

+===================================
+iWARP Multicast Acceleration (IMA)
+===================================
+
+iWARP multicast acceleration bases on new defined QP
+type IBV_QPT_RAW_ETH. Adding a IBV_QPT_RAW_ETH enables
+a L2 traffic kernel bypass  using user-space verbs API.
+
+The L2 RAW_ETH acceleration assumes that user application
+transmits and receives a whole L2 frame including MAC/IP/UDP/TCP headers.
+
+ETH RAW QP usage:
+first the application creates IBV_QPT_RAW_ETH QP with associated CQ,PD,
+completion channels as it is performed for RDMA connection.
+
+Next step is enabling L2 MAC address RX filters for directing received
+multicasts to the RAW_ETH QPs using ibv_attach_multicast() verb.
+
+From this point the application is ready to receive and transmit
+multicast traffic.
+
+In multicast acceleration the user application passes to ibv_post_send()
+whole IGMP frame including MAC header, IP header, UDP header and UDP payload.
+It is a user responsibility to make IP fragmentaion when required payload
+is larger than MTU. Every fragment is a separate L2 frame to transmit.
+The ibv_poll_cq() provides an information about the status of transmit buffer.
+
+On receive path when ibv_poll_cq() provides an information
+about received L2 packet, the Rx buffer (previously posted by ibv_post_recv()
+ contains a whole L2 frame including MAC header, IP header and UDP header.
+It is a user application responsibility to check if received packet is
+a valid UDP frame so the fragments must be checked and
+checksums must be computed.
+
+IMA API description (NE020 specific) :
+User application must create separate CQs for RX and TX path.
+Only single sge on tranmit is supported.
+User application must post at least 65 rx buffers to keep RX path  working.
+
+IMA device:
+IMA requires creation of the /dev/infiniband/nes_ud_sksq device to get
+ access to optimized IMA transmit path. The best method for creation
+of that device is manual addition following line to
+/etc/udev/rules.d/90-ib.rules file
+after OFED distribution installation and rebooting machine.
+
+KERNEL=="nes_ud_sksq", NAME="infiniband/%k", MODE="0644"
+
+As a result the 90-ib.rules should look like:
+
+KERNEL=="umad*", NAME="infiniband/%k"
+KERNEL=="issm*", NAME="infiniband/%k"
+KERNEL=="ucm*", NAME="infiniband/%k", MODE="0666"
+KERNEL=="uverbs*", NAME="infiniband/%k", MODE="0666"
+KERNEL=="ucma", NAME="infiniband/%k", MODE="0666"
+KERNEL=="rdma_cm", NAME="infiniband/%k", MODE="0666"
+KERNEL=="nes_ud_sksq", NAME="infiniband/%k", MODE="0644"
+
+Keep in mind that setting an other that 644 mode of nes_ud_sksq device
+can cause serious serious security issues, so it is not recommended to
+change this mode for applications.

 NetEffect is a trademark of Intel Corporation in the U.S. and other countries.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20100617/cbbe1e8d/attachment.html>