The prepares to kill device private fields in channel struct, which
are not flexible and extensible.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7243
In case that VMBUS_CHAN_ISPRIMARY is needed in the early place of
channel setup.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7108
This paves way for the further cleanup/disentangle.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7092
This paves way to nuke the hv_device, which is actually an unncessary
indirection.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7033
This prepares to remove the unnecessary offer message embedding in
hv_vmbus_channel.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7015
This prepares to remove the unnecessary offer message embedding in
hv_vmbus_channel.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D7014
For multi-channel devices, once the primary channel is closed,
a set of 'rescind' messages for sub-channels will be delivered
by Hypervisor. Sub-channel MUST be freed according to these
'rescind' messages; directly re-openning sub-channels in the
same fashion as the primary channel's re-opening does NOT work
at all.
After the primary channel is re-opened, requested # of sub-
channels will be delivered though 'channel offer' messages, and
this set of newly offered channels can be opened along side with
the primary channel.
This unbreaks the MTU setting for hn(4), which requires re-
openning all existsing channels upon MTU change.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6978
Instead of global variable, vmbus version is accessed through
a vmbus DEVMETHOD now.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6953
This greatly reduces the oqdrops under heavy workload.
For TCP send/recv test (10K concurrent connections):
oqdrops is reduced by 17% on sending side, and 57% on receiving side.
For nginx-1.8/wrk-4 1KB object test (10K concurrent connections,
4 requests/connection):
oqdrops is reduced by 44% on nginx side, and 10% on wrk side.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Since the sub-channel offers are synchronized, we can do our own
channel setup without using the sub-channel creation callback.
This paves the way to whack the sub-channel creation callback.
MFC after: 1 week
Sponsored by: Microsoft OSTC
8 gives the best performance in both Azure and local Hyper-V on both
10Ge and 40Ge. More rings are still allowed by manual configuration.
Reviewed by: Dexuan Cui <decui microsoft com>
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5879
And factor out tcp_lro_rx_done, which deduplicates the same logic with
netinet/tcp_lro.c
Reviewed by: gallatin (1st version), hps, zbb, np, Dexuan Cui <decui microsoft com>
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5725
This mainly used to improve ACK timeliness when multiple RX rings
are enabled.
This value gives the best performance in both Azure and Hyper-V
environment, w/ both 10Ge and 40Ge using non-{INVARIANTS,WITNESS}
kernel.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5691
