This is the first step for VRSS: multiple channel support. It passes build & simple test, and need more test.

Yes, substract the next_gpadl_handle is risk here.

The update includes:

1. Reuse "dev.DEV.UNIT." as sysctl root node instead of defining a new node.
2. Separate the statisitc into two parts: hv_vmbus_channel_stat and hv_ring_buffer_stat. The former is owned by channel module, and the later is for ring_buffer module. Because the statistic needs to know which ring buffer it is: inbound or outbound, that is only known in channel level. It is not suitable to bind all logic to hv_vmbus_ring_buffer_init function even though I tried it but found the logic is not clean.
3. Add the support for sub channel. There is a node "sub" in the output.

My intension of creating more nodes is for printing clear message. We have to distinguish ring buffers on different channels, so they belong to the same node. Maybe we also needs to distinguish subchannels. Now I have not done this.

hmm, it makes sense to put ring_buffer_stats function into hv_ring_buffer.c since only one function exists in that file.

There is another succinct implementation with taskqueue_fast. Please reference https://reviews.freebsd.org/D5215

Since there are some new added files, shall we modify the copyright to "2016"? I remember Sephie said there are some regulations on copyright.

LGTM

Looks ok to me.

LGTM

• hyperv: vmbus: refactor msg handler by replacing swi with task queue

It looks ok to me.

replace "false" with "FALSE" in order to be consistent with other "FALSE" in the same file.

According to howard0su_gmail.com's suggestion, I did corresponding modifications except for "boolean_t==>bool" in order to keep consistent in current file. In the future, I will do a special code refactor in order to align with FreeBSD's mainstream style.

Looks ok to me.

1. When the statistic data was reset or cleared? I found if I enable LRO and run some test, and then disable LRO, the statistic data are still there.
2. Please follow the style (9) for all "return" statement. e.g. "return IPPROTO_DONE;" should be changed to "return (IPPROTO_DONE);"
3. For TUNABLE_INT("dev.hn.trust_hosttcp", &hn_trust_hosttcp); "dev.hn.trust_hosttcp" is not a generic option for network, instead it only makes sense for hyperv network driver, so could you please rename it to be "dev.hyperv.trust_hosttcp"? "hn" makes people think it is "hn0".

refine the patch according to Wei Hu's comments

Could you please help me review the bug fix?