I suspect that means that your BIOS pre-allocated enough bus numbers to the bridge to account for the VFs. Perhaps we should add a pcib method that recursively checks that a contiguous range of bus numbers is assigned to the bridge?
Tue, Oct 8
Tue, Oct 1
Aug 27 2019
Oct 4 2018
Sep 19 2018
Jun 12 2018
@rstone do you think you might be able to share the work that you or Jeff did on the frontend to adaptively lower the minRTO if the pipe was full?
May 17 2018
I do not see such code in mlx4_en_rx.c. Could you point it out, please ?
May 16 2018
Well, from my reading, your patch and this patch are quite similar, but this review provides two interesting optimizations.
- Use page-size fragments if MTU >= PAGE_SIZE, already discussed on lists for mlx5.
- Keep around mbufs and memory for unused fragments, if the received packed was shorter than MTU.
If these changes are transplanted into your patch, I believe the things start look almost identical. I want to confirm my understanding with Ryan.
May 7 2018
The message that I got at BSDCan last year is that they wanted to see at least a full IETF draft before these changes could be merged in, which is why my work on it stalled. Has people's position on this changed?
FWIW, I had a short email conversation with the writers of that draft about a year ago and they went radio silent pretty quickly. I assumed that they weren't working on it anymore.
Mar 19 2018
Mar 14 2018
Where is route.subr? And where did ipv4_move_subnet_route come from? I think you used the wrong base revision to generate the review.
Move non-fib test into separate test file
Mar 8 2018
Mar 7 2018
I've written some unit tests that covering these cases here:
Mar 5 2018
I don't think that this conversation is going to go anywhere productive. Do you have specific technical objection to raise about this change?
Care to elaborate what are you trying to achieve by moving subnet route between interfaces?
Uploaded the wrong test to this review; fixed now
Move route(8) tests to their own atf test file
In any case, even if the use-case is weird, the current behaviour is clearly buggy and needs to be fixed in some way.
Well, I guess so. But original configuration may be supposed to be "buggy" too (read: not supported). What if you use /16 mask for single interface only and assign IP from the same prefix to other interfaces using /32 mask?
Mar 1 2018
And you do you insist in doing things manually while moving IP (first route change, then reassign IP) instead of just allowing system do all housekeeping for you by reassigning IP first?
Add ATF test cases for IPv4/IPv6 subnet route migration
The fibs must actually exist. Set net.fibs=6 in /boot/loader.conf and reboot. Also, are you sure you need so many? I don't think there are any tests there that require more than two.
In tests/sys/netinet/fibs_test.sh there are some ATF tests that check this kind of functionality. They do it on separate FIBs so they won't upset the system running the tests, and they use tap(4) and/or epair(4) interfaces. You should be able to copy one of those to create a regression test for this problem.
Feb 28 2018
Check for NULL pointers
Feb 21 2018
Feb 16 2018
How it supposed to work for RADIX_MPATH case? I know RADIX_MPATH is currently broken, but anyway...
Clarify manpage update as per rgrimes' suggestion
Fix the manpage to document that the gateway parameter is
optional for most route subcommands.
Feb 10 2018
Jan 29 2018
Jan 23 2018
Jan 22 2018
Add comment explaining generation increment
Jan 19 2018
NULL-out rte after route cache is invalidated
Dec 14 2017
Dec 13 2017
It would be nice if you describe why this leak happens, i.e. where leaked reference was acquired.
Dec 7 2017
Nov 17 2017
Oct 24 2017
Oct 23 2017
Oct 16 2017
Oct 11 2017
Sep 22 2017
Sep 12 2017
Aug 15 2017
Aug 4 2017
Aug 2 2017
Jul 31 2017
Jul 20 2017
Jul 13 2017
Jul 12 2017
Don't pull the "old behaviour" into the driver. You should use a linked list of mbufs and load that instead of the mlx4_en_frag_info structure now we are using busdma!
There is a better way to implement this. Can Mellanox take over this issue?
Jul 11 2017
Jun 27 2017
May 29 2017
@kmacy I have not. We probably have an equivalent fix committed locally @ $WORK but it might be tied too closely to the high-precision timestamp work to easily extract.
May 24 2017
May 3 2017
Maybe you've seen something that requires this lock acquisition in your testing. Can you explain why we need to acquire this lock here?
Apr 28 2017
Apr 5 2017
Apr 3 2017
Add the locking mentioned the description but omitted from the
I'm not sure what we want to do with this fix given the imminent iflib conversion, but at least this should go into stable branches.
Mar 22 2017
Obsoleted by gleb's User/Kernel KPI fixes
Feb 23 2017
Feb 18 2017
Feb 17 2017
Feb 16 2017
Feb 15 2017
I realize the issue there is exposure of a type definition to userland, but a related question is - what exactly is the userland-ABI property we are trying to maintain here? Are we just trying to keep this struct the same size and layout under all kernel configuration option selections and feature evolutions for a given machine type? Or are we also trying to keep it the same size and layout across different machine types (or at the very least a single pair of relevant machine types)? For example, is the #ifdef_LP64 really necessary in the TCPPCAP section?