the same diff but more context.

In D41592#953793, @erj wrote:

I was preparing to push this yesterday, but I forgot to do the last step; I think @anzhu_netapp.com has a good point here because it'll reduce the number of VIMAGE blocks, but I probably would still push it and would just wait for a fix later.

In D41425#945229, @jhibbits wrote:

I'm not familiar enough to comment at all. My only role was mechanically converting to IfAPI.

In D41425#944908, @erj wrote:

I wish this was uploaded with context, but I'm not an expert on RDMA so I'm not sure it would let me review this code better.

That said, I see some checks for FreeBSD 14.0; is this patch something that is intended to be directly MFC-able to stable/13?

Thank you @jhibbits i started a testing automation on our side to double check.
Unfortunately i'm going out for holidays, so i won't be able to report on that. I'll ask someone to cover for me during this time, and to let you know if the testing went good.

I'm attaching current proposal which i rebased on top of 14-cur today and run quickly rping on roce/iwarp and it seems fine.

In D38960#902485, @jhibbits wrote:

In D38960#902466, @bartosz.sobczak_intel.com wrote:

i still haven't had a chance to test this, because from what i can see the commit 3e142e07675be6d breaks iwarp for E810 devices. i'm trying to comprehend why this happens.

Crap. It should've been a purely mechanical change, with no functional changes. Unfortunately I have no way of testing. @hselasky are you able to test and debug? I hope I don't need to revert, I want to get D39621 in before the branch in May.

i still haven't had a chance to test this, because from what i can see the commit 3e142e07675be6d breaks iwarp for E810 devices. i'm trying to comprehend why this happens.

In D38960#899373, @jhibbits wrote:

Hi @bartosz.sobczak_intel.com I just checked, and the diffs are identical. I have no way of testing it, I've only compiled it for all targets.

I'm not sure how (and if i can) do direct changes onto this review.

The changes may be applied to most recent code for OOT releases, so there is not much reason to hold back on that part.
Please fix the function description marked previously.

some of the changes need to be back-ported to 13 and 12 OS, to not diverge too much from the core code.
The cm code is shared with linux driver, so i am going to check if we can take advantage of that.

Applied changes suggested to the man page and NOTES

Several changes have been done to the driver code:

• adjustments against future changes in if_ixl driver,
• adjustments preparing for making VIMAGE a default option in kernel configuration,
• adding support for BSD_RDMA_4_9 branch of FreeBSD-CURRENT kernel,
• implementing IPv6 support for BSD_RDMA_4_9 branch,
• fix minor problem with traffic on tagged vLAN,
• fix for fast memory registration issue with stag update.

In D11378#272139, @np wrote:

In D11378#247102, @erj wrote:

In D11378#247048, @sbruno wrote:

@erj are you going to commit this once you've made the IXL updates required for it to function?

Yeah, that's the plan. If @bartosz.sobczak_intel.com is okay with the current version.

This will collide with the the projects/bsd_rdma_4_9 branch. Have you looked at that?

See this message too:
https://lists.freebsd.org/pipermail/freebsd-infiniband/2017-November/000364.html

Removing additional errors in READMEs.
Improving casts handling - thanks for pointing this out!

In D11378#242202, @sbruno wrote:

I don't think these are very significant, but I get the following warnings during a build:

/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_utils.c:943:46: warning: taking address of packed member 'ip6_dst' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_ntohl(loc_addr, (__be32 *) & ip6h->ip6_dst);
                                                           ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_utils.c:944:46: warning: taking address of packed member 'ip6_src' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_ntohl(rem_addr, (__be32 *) & ip6h->ip6_src);
                                                           ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:488:36: warning: taking address of packed member 'ip6_src' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_htonl((__be32 *) & ip6h->ip6_src,
                                                 ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:490:36: warning: taking address of packed member 'ip6_dst' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_htonl((__be32 *) & ip6h->ip6_dst,
                                                 ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:3046:22: warning: taking address of packed member 'ip6_dst' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                                    (__be32 *) & ip6h->ip6_dst);
                                                 ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:3048:22: warning: taking address of packed member 'ip6_src' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                                    (__be32 *) & ip6h->ip6_src);

iw_ixl.4 : few more links that should be marked with .Lk changed

Changes suggested by wblock are applied.
minor other changes to the readme.
small code cleanup.
server_inv bugfix.
version bump to 0.1.11.

Adding the module for compilation with buildkernel.

Added manual page iw_ixl.4 to share/man/man4/

In D11378#235446, @sbruno wrote:

This doesn't appear to be connected to the kernel build via sys/conf/files. It also does not have a kernel config option via sys/conf/options.