ib_create_send_mad(9)
π ib_create_send_mad(9) β a Kernel API Manual moment
okay so bestie, we're diving into the Kernel API Manual today and honestly? this one's a little gem. it's ib_create_send_mad, and it's about to hand you a whole send-ready MAD situation. let's get into it π«Ά
β¨ NAME β¨
ib_create_send_mad β allocate and initialize a data buffer plus a work request, all for sending a MAD. yes, both things, one call. we love an efficient icon π
πΈ SYNOPSIS πΈ
struct ib_mad_send_buf * ib_create_send_mad (struct ib_mad_agent
*mad_agent , u32 remote_qpn , u16 pkey_index , int rmpp_active , int
hdr_len , int data_len , gfp_t gfp_mask , u8 base_version );
eight arguments. count 'em. she's thorough π
π ARGUMENTS π
mad_agentβ the registered MAD service you're associating with the MAD. like, who's this MAD for? this guy. π€remote_qpnβ the QPN of the receiving node, i.e. where this thing is headed.pkey_indexβ which PKey the MAD will be sent using. β οΈ heads up: this field is valid only if theremote_qpnis QP 1. no cap.rmpp_activeβ tells you if the send will enable RMPP.hdr_lenβ the size of the data header of the MAD. and this length should include the common MAD header, the RMPP header, plus any class specific header. yes, all three, don't leave anybody out πdata_lenβ the size of any user-transferred data. and good news: the call will automatically adjust the allocated buffer size to account for any additional padding that may be necessary. it's giving "we handled it" β¨gfp_maskβ the GFP mask used for the memory allocation. the allocation lore π§base_versionβ Base Version of this MAD. periodt.
π¦ DESCRIPTION π¦
so this routine allocates a MAD for sending. the returned MAD send buffer will reference a data buffer usable for sending a MAD, along with an initialized work request structure. two-for-one, main character energy π
and here's the fun part: users may modify the returned MAD data buffer before posting the send. it's yours, customize away π¨
now the deets you actually need to remember: the returned MAD header, class specific headers, and any padding will be cleared. so who's responsible for initializing the common MAD header, any class specific header, and the MAD data area? that would be you, bestie π don't forget, fr fr.
one lil exception though β if rmpp_active is set, the RMPP header will be initialized for sending. so that part's handled. slay π
π SEE ALSO π
kernel file ./include/rdma/ib_mad.h, plus this whole friend group right here:
ib_get_cpi_resp_time(9)ib_get_cpi_capmask2(9)ib_set_cpi_capmask2(9)opa_get_cpi_capmask2(9)ib_response_mad(9)ib_get_rmpp_resptime(9)ib_get_rmpp_flags(9)ib_set_rmpp_resptime(9)ib_set_rmpp_flags(9)ib_register_mad_agent(9)ib_unregister_mad_agent(9)ib_post_send_mad(9)ib_free_recv_mad(9)ib_modify_mad(9)ib_cancel_mad(9)ib_is_mad_class_rmpp(9)ib_get_mad_data_offset(9)ib_get_rmpp_segment(9)ib_free_send_mad(9)ib_mad_kernel_rmpp_agent(9)
and that's the whole vibe check, bestie π«Ά this page lives in ./include/rdma, dated October 2026, and it'll always answer to the name ib_create_send_mad(9). go forth and send those MADs π
πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms