• fixup! Don't zero out srtt after excess retransmits

See this ML post for a detailed description of the problem:
https://lists.freebsd.org/pipermail/freebsd-current/2013-January/039261.html

Ensure we don't walk off the end of the ring

--git-dir is unreliable, so use -C $git_repo instead

Similar fix is needed in importgit

This is not the correct fix. The bug lies in a higher layer; the stack must never call into the ifnet layer with the if_addr_lock already held. I see how to fix the upper layer, so I'll take that.

Add -n option to arcgit to perform a dry run, and fix some typos.

Add sysctl to control new UDP receive behaviour, and document it
in UPDATING.

I already have this one in review. I'm trying to address some concerns that have been raised outside of phabricator, and once that's taken care of I'll commit my version.

so apparently this is called on nearly every packet that passes through ip_output() (according to a comparison of dtrace and netstat output). Adding an additional lock/unlock to the transmit path concerns me, but this is obviously the right fix. Does in_broadcast() really need to be called so much?

Use macros for code compiled in kernel

Have we tested the case where there is only a single flow, so all of the flowids are equal? That tends to be a very bad case for qsort.

Changing pm_reg to uint16_t was done because the SR-IOV BARs are located outside of the 256-byte PCI configuration space (they are in the extended config space).

nvlist not being backmerged yet was why I haven't yet MFC'ed SR-IOV. That's long overdue, though. It was originally promised to me that would happen for 10.1-RELEASE.

Thanks for fixing this