On Thu, Nov 13, 2014 at 9:54 PM, <ira.weiny@xxxxxxxxx> wrote: > The following patch series modifies the kernel MAD processing (ib_mad/ib_umad) > and related interfaces to process Intel Omni-Path Architecture MADs on devices > which support them. So this series allows to process such mad when it arrives or goes beyond that and allows to send such mad too? > In addition to supporting some IBTA management classes, OPA devices use MADs > with lengths up to 2K. These "jumbo" MADs increase the performance of > management traffic. Can you provide 1-2 use cases where such mads will be sent and by what entity? I recall 2KB mads were mentioned over our LWG talks 8 years ago on IB routers... > To distinguish IBTA MADs from OPA MADs a new Base Version is introduced. The > new format shares the same common header with IBTA MADs which allows us to > share most of the MAD processing code when dealing with the new Base Version. > > > The patch series is broken into 3 main areas. > > 1) Add the ability for devices to indicate "jumbo" MAD support. In addition, > modify the ib_mad module to detect those devices and allocate the resources > for the QPs on those devices. > > 2) Enhance the interface to the device agents to support larger and variable > length MADs. > > 3) Add support for creating and processing OPA Base Version MADs including > a new SMP class version specific to OPA devices. > > > [RFC PATCH 01/16] ib/mad: rename is_data_mad to is_rmpp_data_mad > [RFC PATCH 02/16] ib/core: add IB_DEVICE_JUMBO_MAD_SUPPORT device cap > [RFC PATCH 03/16] ib/mad: Add check for jumbo MADs support on a device > [RFC PATCH 04/16] ib/mad: add base version parameter to > [RFC PATCH 05/16] ib/mad: Add MAD size parameters to process_mad > [RFC PATCH 06/16] ib/mad: Create jumbo_mad data structures > [RFC PATCH 07/16] ib/mad: create a jumbo MAD kmem_cache why not use a single kmem-cache instance with a non hard coded element size, 256B (or whatever we use today) or 2KB? Also (nit), please change the prefix for all patches to be IB/mad: and not ib/mad: to comply with the existing habit of patch titles for the IB subsystem And (another nit), generate patch 0/N using $ git format-patch --cover-letter so we have the exact subject line for each patch and the over-all diffstat in the cover-letter > [RFC PATCH 08/16] ib/mad: Add Intel Omni-Path Architecture defines > [RFC PATCH 09/16] ib/mad: Implement support for Intel Omni-Path > [RFC PATCH 10/16] ib/mad: Add registration check for Intel Omni-Path > [RFC PATCH 11/16] ib/mad: create helper function for > [RFC PATCH 12/16] ib/mad: create helper function for > [RFC PATCH 13/16] ib/mad: create helper function for > [RFC PATCH 14/16] ib/mad: Create helper function for SMI processing > [RFC PATCH 15/16] ib/mad: Implement Intel Omni-Path Architecture SMP > [RFC PATCH 16/16] ib/mad: Implement Intel Omni-Path Architecture General -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
