Closed by 2a3716432d

In D41540#953513, @sanastasio_raptorengineering.com wrote:

Also, thank you @jhibbits for approving the patch. I'm not super familiar with the FreeBSD contribution work flow yet, so excuse the question, but is there anything that I need to do at this point to have this patch committed? I presume the patch must now be merged by someone other than me with commit privileges.

As long as it doesn't require VSX (able to run on PowerMac G5), I think it's good.

Overall this looks good, just the one comment on SPE. Can you also test with powerpc64 BE to avoid surprises?

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

Big "Oops", sorry.

I agree with option 1, moving the LLE insertion code to if_llatbl.c

Switch to a boolean, if_maddr_empty() instead.

In D39621#908256, @melifaro wrote:

If it builds, I'm all up for it!

@mateusz.moga_intel.com Thanks for validation, I'll push it today.

Add mw@ for review as well.

Ping? Would a simple boolean be better than a count?

Ping anyone?

Update diff after (several) rebases. Intended to do this 2 months ago. I hope I've addressed everything.

Rebase and use @bartosz.sobczak_intel.com 's diff instead.

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

d38960_3.diff30 KBDownload

Thanks for bearing with me @jhibbits !

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.

Hi @bartosz.sobczak_intel.com the ofed fix has been committed as 12e99b63d2fa, thanks!

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

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 know! right?
Ok, i think i found the change:

@@ -176,13 +176,13 @@ static inline int rdma_addr_gid_offset(struct rdma_dev_addr *dev_addr)
 	return dev_addr->dev_type == ARPHRD_INFINIBAND ? 4 : 0;
 }
 
-static inline u16 rdma_vlan_dev_vlan_id(const struct ifnet *dev)
+static inline u16 rdma_vlan_dev_vlan_id(if_t dev)
 {
 	uint16_t tag;
 
-	if (dev->if_type == IFT_ETHER && dev->if_pcp != IFNET_PCP_NONE)
+	if (if_gettype(dev) != IFT_ETHER || if_getpcp(dev) == IFNET_PCP_NONE)
 		return 0x0000;	/* prio-tagged traffic */
-	if (VLAN_TAG(__DECONST(struct ifnet *, dev), &tag) != 0)
+	if (VLAN_TAG(__DECONST(if_t, dev), &tag) != 0)
 		return 0xffff;
 	return tag;
 }

So we have a change from:
A && !B
into:
!A || B

Do you know why this change? It clearly is a negative of what was before. The effect is that when no vlan is set, we get vlan_id 0 instead of 0xffff, and this is used by irdma driver.

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.

Ah I see now. Not sure what I actually downloaded to check yesterday, now I got the right diff to compare.

powerpcspe can be done separately. I don't think there's currently any attribute used, but if there will be it would be "spe" or such.

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.

In D39491#899046, @hselasky wrote:

When changing structure layouts you need to bump the FreeBSD version.

Rebase, address feedback.

Drop the initial link state. Nothing else sets initial link state.

In D38929#893449, @erj wrote:

In D37856#893389, @zlei wrote:

Looks good to me.

I admit that the diff https://reviews.freebsd.org/D37856?id=117248 frustrated me a lot.

Update.

Any further comments on this?

Update to use the new if_iter API. Remove rest of struct ifnet uses in the code.

@erj can you fix this the right way given what you also wrote in your now deleted comment? I could just revert the original change to the line if that's all that's needed.

@bartosz.sobczak_intel.com I'm find holding off. When D39173 is committed I'll rebase on that and rework to also use the new iterator API which is cleaner than the callback API.

Simplify things a bit, store only next pointer instead of both current and next.

Address feedback from @melifaro. Make the API 'safe', and change the cleanup function to 'finish'.

@melifaro I like that approach overall, but I think it's nicer to keep it all local on the stack using an opaque context struct, then a user can do something like: