User Details
- User Since
- Sep 28 2014, 7:22 PM (442 w, 4 d)
Today
Protect tailq operation with the bucket lock.
Yesterday
Remove unrelated changes.
Mon, Mar 20
Sat, Mar 18
Fri, Mar 17
Rebase on top of netlink-ified carp
Remove sleep
Thu, Mar 16
The epoch system serves to make sure that resources we rely on (such as the ifp, or route or neighbour objects) don't go away while we're using them. It's pretty unlikely for them to actually go away in the tiny slice of time where it'd matter, so it's completely normal that you didn't see any issues even with the missing epoch calls.
It'd be good to add this case to the carp tests. Can you? If not, I'll take a look. I'm doing some carp work as well anyway.
Wed, Mar 15
Tue, Mar 14
Use attributes (i.e. TLV) for everything.
Review remarks
ping6 -> ping -6
Mon, Mar 13
Full patch this time.
Wed, Mar 8
I wouldn't describe the traffic as forged. (And I was wrong, it's not a multicast MAC address, but a "virtual router MAC address"). The VRRP standard at least explicitly requires that address to be used. CARP isn't formally standardised (at least that I could find), but it behaves very like VRRP.
In any event, we need to do things slightly differently to make them work in cloud setups.
If I'm reading this right there's a userspace visible change in definitions (e.g. struct route is no longer visible without _KERNEL). If so, should we do an exp-run over the ports to see what the fallout is going to be like?
It doesn't. Yesterday I discovered that the current version of the patch doesn't work in AWS, because it changes the source MAC address to a multicast address. I've got a fix for that (i.e. don't change the MAC address in unicast mode) that allows it to work in AWS. Even in promiscuous mode the multicast traffic never arrives, so we do need this at least for AWS, and it would be useful for ESXi to avoid needing to run interfaces in promiscuous mode.
Tue, Mar 7
I'm a little torn on how to handle the extension in the interface to userspace. I've added a new ioctl for it, but we could also extend the struct (and then teach the existing ioctl to cope with two sizes of structure), or we could convert the whole thing to using netlink, to make future extensions easier.
We're failing a couple of test cases in /usr/tests/sbin/pfctl with this patch. At least one of the failures is due to the duplicate allow-opts, so an easy fix.
Mon, Mar 6
With the patch that seems to fail to build on armv6 (and I suspect on i386 as well):
Also, somewhat random question: are we keeping the programming API identical (or close to) Linux?
That's not bad at all. It seems to perform about as well as the current copy-structs-around ioctl() interface.
Sat, Mar 4
Yeah, my test box has vm.ndomains: 2.
This version is much, much faster than the pervious, and it does make the code simpler to reason about (than what we had before) as well.
Fri, Mar 3
Thu, Mar 2
The intent was also to avoid locking between the sender and receiver side.
Re-running my test setup shows 889.672 Kpps without this change, and with it I see 42.635 Kpps. That's kind of a steep hit.