date:20160204

RE: Hyper-V networking: problem after upgrade to 10.2

2016-02-04 Thread Dexuan Cui

Hi Jac,
The easiest way to get the fixes is just using the latest stable/10 branch as I 
mentioned in another mail.

Alternatively, if you want to use your local 10.2 source code in /usr/src/  + 
the fixes only, please read the below:

I put the 10.2-specific fixes onto my github branch "decui/10.2/fix_mac_order" 
(please see the top 2 patches) :
https://github.com/dcui/freebsd/commits/decui/10.2/fix_mac_order (I resolved a 
small code conflict)

I verified the 2 patches could be cleanly applied to a clean installation of 
10.2 VM:

[root@decui-bsd102 /usr/src]# pwd
/usr/src
[root@decui-bsd102 /usr/src]# wget 
https://github.com/dcui/freebsd/commit/b706b383da285376554bcb69f44c4cc10270de24.patch
--2016-02-04 13:37:04--  
https://github.com/dcui/freebsd/commit/b706b383da285376554bcb69f44c4cc10270de24.patch
Resolving github.com (github.com)... 192.30.252.131
Connecting to github.com (github.com)|192.30.252.131|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: 'b706b383da285376554bcb69f44c4cc10270de24.patch.1'

b706b383da285376554bcb69f44c4cc10270de24.pa [ <=>   
]   7.13K  --.-KB/s 
  in 0.006s

2016-02-04 13:37:05 (1.22 MB/s) - 
'b706b383da285376554bcb69f44c4cc10270de24.patch.1' saved [7297]

[root@decui-bsd102 /usr/src]# patch -sp1 < 
b706b383da285376554bcb69f44c4cc10270de24.patch
[root@decui-bsd102 /usr/src]# wget 
https://github.com/dcui/freebsd/commit/2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch
--2016-02-04 13:37:26--  
https://github.com/dcui/freebsd/commit/2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch
Resolving github.com (github.com)... 192.30.252.129
Connecting to github.com (github.com)|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: '2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch.1'

2bff041dbed26b5da88c4be72b4701bbf6c460cd.pa [ <=>   
]   4.22K  --.-KB/s 
  in 0.003s

2016-02-04 13:37:27 (1.31 MB/s) - 
'2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch.1' saved [4323]

[root@decui-bsd102 /usr/src]# patch -sp1 < 
2bff041dbed26b5da88c4be72b4701bbf6c460cd.patch
[root@decui-bsd102 /usr/src]#

If the related files in your /usr/src/sys/dev/hyperv/ were messed up by the 
previous failed patch commands, you can replace the files with the version here 
(https://github.com/dcui/freebsd/tree/decui/10.2/fix_mac_order/sys/dev/hyperv. 
You can use the "Raw" format functionality to get the related URLs of the files 
and use 'wget' to get them):
sys/dev/hyperv/include/hyperv.h
sys/dev/hyperv/vmbus/hv_channel_mgmt.c
sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.c
sys/dev/hyperv/vmbus/hv_vmbus_priv.h

Please let me know if this will work for you.

Thanks,
-- Dexuan

From: Jac Backus [mailto:j.bac...@bugworks.com]
Sent: Thursday, February 4, 2016 7:18
To: Dexuan Cui ; Sephe Qiao (Wicresoft) 
; Kylie Liang ; 
'freebsd-virtualization@freebsd.org' ; BSD 
Integration Components for Hyper-V 
Subject: RE: Hyper-V networking: problem after upgrade to 10.2

Hello Dexuan,

The first patch gives no messages.
When trying the second:

112 # patch -sp1 < 1e469c559048fe6ec3641da3bb21ab87215c6506.patch
1 out of 7 hunks failed--saving rejects to 
sys/dev/hyperv/vmbus/hv_channel_mgmt.c.rej

Attached you find the patched file (as a session log).

With kind regards,

Jac



Van: Dexuan Cui [mailto:de...@microsoft.com]
Verzonden: woensdag 3 februari 2016 10:05
Aan: Jac Backus; Sephe Qiao (Wicresoft); Kylie Liang; 
'freebsd-virtualization@freebsd.org'; BSD Integration Components for Hyper-V
Onderwerp: RE: Hyper-V networking: problem after upgrade to 10.2

Thanks for the confirmation, Jac.

I might be wrong with 10.1 - it may not have the issue.
In 10.2 we made a lot of changes and I think the race condition was introduced.

To test the 2 patches, you can do something like

cd /usr/src
(supposing the 10.2 kernel code is in the sys/ sub-directory)
wget 
https://github.com/freebsd/freebsd/commit/850d0994e48b0ef68d33875e26326d44931fcf1e.patch
patch -sp1 < 850d0994e48b0ef68d33875e26326d44931fcf1e.patch
wget 
https://github.com/freebsd/freebsd/commit/1e469c559048fe6ec3641da3bb21ab87215c6506.patch
patch -sp1 < 1e469c559048fe6ec3641da3bb21ab87215c6506.patch
make buildkernel KERNCONF=GENERIC -j8
make installkernel
reboot

You may get a small issue when applying the second patch as I did:
1 out of 8 hunks failed--saving rejects to 
sys/dev/hyperv/vmbus/hv_channel_mgmt.c.rej
You can fix this by checking the .patch/.c files and manually editing the .c 
file.

Thanks,
-- Dexuan

From: Jac Backus [mailto:j.bac...@bugworks.com]
Sent: Wednesday, February 3, 2016 16:10
To: Dexuan Cui

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread sepherosa_gmail.com (Sepherosa Ziehau)

sepherosa_gmail.com added a comment.


  I will adjust the patch accordingly.

INLINE COMMENTS
  sys/netinet/tcp_lro.c:655 Sure :)
  sys/netinet/tcp_lro.c:684 Sounds fine to me.  I did the byte limit before 
(https://reviews.freebsd.org/D4825).  But it turns out the ACKs need seperate 
limit (append count based).  To make them consistent, I changed the original 
patch to use append count too.

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin
Cc: freebsd-virtualization-list, freebsd-net-list
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread sepherosa_gmail.com (Sepherosa Ziehau)

sepherosa_gmail.com added inline comments.

INLINE COMMENTS
  sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c:455 OK, I will split it out.

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin
Cc: freebsd-virtualization-list, freebsd-net-list
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

[Differential] [Closed] D5175: hyperv/hn: Add an option to always do transmission scheduling

2016-02-04 Thread Phabricator

This revision was automatically updated to reflect the committed changes.
Closed by commit rS295306: hyperv/hn: Add an option to always do transmission 
scheduling (authored by sephe).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D5175?vs=12968=13040#toc

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D5175?vs=12968=13040

REVISION DETAIL
  https://reviews.freebsd.org/D5175

AFFECTED FILES
  head/sys/dev/hyperv/netvsc/hv_net_vsc.h
  head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c

CHANGE DETAILS
  diff --git a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c 
b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
  --- a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
  +++ b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
  @@ -534,6 +534,10 @@
SYSCTL_ADD_INT(ctx, child, OID_AUTO, "direct_tx_size",
CTLFLAG_RW, >hn_direct_tx_size, 0,
"Size of the packet for direct transmission");
  + SYSCTL_ADD_INT(ctx, child, OID_AUTO, "sched_tx",
  + CTLFLAG_RW, >hn_sched_tx, 0,
  + "Always schedule transmission "
  + "instead of doing direct transmission");
   
if (unit == 0) {
struct sysctl_ctx_list *dc_ctx;
  @@ -1602,26 +1606,31 @@
   static void
   hn_start(struct ifnet *ifp)
   {
  - hn_softc_t *sc;
  + struct hn_softc *sc = ifp->if_softc;
  +
  + if (sc->hn_sched_tx)
  + goto do_sched;
   
  - sc = ifp->if_softc;
if (NV_TRYLOCK(sc)) {
int sched;
   
sched = hn_start_locked(ifp, sc->hn_direct_tx_size);
NV_UNLOCK(sc);
if (!sched)
return;
}
  +do_sched:
taskqueue_enqueue_fast(sc->hn_tx_taskq, >hn_start_task);
   }
   
   static void
   hn_start_txeof(struct ifnet *ifp)
   {
  - hn_softc_t *sc;
  + struct hn_softc *sc = ifp->if_softc;
  +
  + if (sc->hn_sched_tx)
  + goto do_sched;
   
  - sc = ifp->if_softc;
if (NV_TRYLOCK(sc)) {
int sched;
   
  @@ -1633,6 +1642,7 @@
>hn_start_task);
}
} else {
  +do_sched:
/*
 * Release the OACTIVE earlier, with the hope, that
 * others could catch up.  The task will clear the
  diff --git a/head/sys/dev/hyperv/netvsc/hv_net_vsc.h 
b/head/sys/dev/hyperv/netvsc/hv_net_vsc.h
  --- a/head/sys/dev/hyperv/netvsc/hv_net_vsc.h
  +++ b/head/sys/dev/hyperv/netvsc/hv_net_vsc.h
  @@ -1023,6 +1023,7 @@
int hn_txdesc_avail;
int hn_txeof;
   
  + int hn_sched_tx;
int hn_direct_tx_size;
struct taskqueue *hn_tx_taskq;
struct task hn_start_task;

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
howard0su_gmail.com, adrian, network, honzhan_microsoft.com
Cc: freebsd-virtualization-list, freebsd-net-list
diff --git a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
--- a/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
+++ b/head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
@@ -534,6 +534,10 @@
 	SYSCTL_ADD_INT(ctx, child, OID_AUTO, "direct_tx_size",
 	CTLFLAG_RW, >hn_direct_tx_size, 0,
 	"Size of the packet for direct transmission");
+	SYSCTL_ADD_INT(ctx, child, OID_AUTO, "sched_tx",
+	CTLFLAG_RW, >hn_sched_tx, 0,
+	"Always schedule transmission "
+	"instead of doing direct transmission");
 
 	if (unit == 0) {
 		struct sysctl_ctx_list *dc_ctx;
@@ -1602,26 +1606,31 @@
 static void
 hn_start(struct ifnet *ifp)
 {
-	hn_softc_t *sc;
+	struct hn_softc *sc = ifp->if_softc;
+
+	if (sc->hn_sched_tx)
+		goto do_sched;
 
-	sc = ifp->if_softc;
 	if (NV_TRYLOCK(sc)) {
 		int sched;
 
 		sched = hn_start_locked(ifp, sc->hn_direct_tx_size);
 		NV_UNLOCK(sc);
 		if (!sched)
 			return;
 	}
+do_sched:
 	taskqueue_enqueue_fast(sc->hn_tx_taskq, >hn_start_task);
 }
 
 static void
 hn_start_txeof(struct ifnet *ifp)
 {
-	hn_softc_t *sc;
+	struct hn_softc *sc = ifp->if_softc;
+
+	if (sc->hn_sched_tx)
+		goto do_sched;
 
-	sc = ifp->if_softc;
 	if (NV_TRYLOCK(sc)) {
 		int sched;
 
@@ -1633,6 +1642,7 @@
 			>hn_start_task);
 		}
 	} else {
+do_sched:
 		/*
 		 * Release the OACTIVE earlier, with the hope, that
 		 * others could catch up.  The task will clear the
diff --git a/head/sys/dev/hyperv/netvsc/hv_net_vsc.h b/head/sys/dev/hyperv/netvsc/hv_net_vsc.h
--- a/head/sys/dev/hyperv/netvsc/hv_net_vsc.h
+++ b/head/sys/dev/hyperv/netvsc/hv_net_vsc.h
@@ -1023,6 +1023,7 @@
 	int		hn_txdesc_avail;
 	int		hn_txeof;
 
+	int		hn_sched_tx;
 	int		hn_direct_tx_size;
 	struct taskqueue *hn_tx_taskq;
 	struct task	hn_start_task;

___
freebsd-virtualization@freebsd.org mailing list

[Differential] [Updated] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread gallatin (Andrew Gallatin)

gallatin added a comment.


  It might be nice to make these general tunables that could be done centrally 
and apply to all drivers, but that's probably outside the scope of the review.

INLINE COMMENTS
  sys/netinet/tcp_lro.c:655 Can you just initialize ack_append_limit to the max 
value for whatever type it is and eliminate the check for a 0 ack_append_limit? 
 That would eliminate one clause from this conditional.
  sys/netinet/tcp_lro.c:684 Rather than adding more clauses to this condition,  
how would to feel about setting an append limit in bytes, and replacing the 
hard-coded 65535 with this new limit?   The default lro init would initialize 
the new limit to 65535.  And hn(4) would initialize it in terms of multiples of 
its MTU.

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin
Cc: freebsd-virtualization-list, freebsd-net-list
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: AMD CPUs

2016-02-04 Thread Gerd Hafenbrack

On 2016-02-04 13:21, Roger Pau Monné wrote:
> El 4/2/16 a les 11:59, Gerd Hafenbrack ha escrit:
>> Hello,
>>
>> I read on http://wiki.xen.org/wiki/FreeBSD_Dom0 the following:
>>> ... to run a FreeBSD PVH Dom0 an Intel box with EPT and a working IOMMU is 
>>> required.
>>
>> Why only intel and not an AMD CPU with Rapid Virtualization Indexing
>> (RVI) and IOMMU as well?
> 
> There's no technical reason on why this was done this way. It's just
> that the original PVH implementation inside of Xen was badly designed,
> and one of the results is the lack of support on AMD hardware. This is
> not related to FreeBSD at all, Linux has the same exact problem.
> 
> I'm (together with other people) currently working on removing this (and
> other) stupid limitation by doing a proper implementation of PVH inside
> of Xen. This new implementation is ATM called HVMlite. Sadly I can not
> yet provide an ETA on when this is going to be finished. Once HVMlite is
> finished inside of Xen FreeBSD will hopefully be able to run on AMD
> hardware just like it does on Intel one. I will do a HEADS UP once this
> is in testing state.
> 
> Roger.

Thx.

I have to use an AMD box.

In the meantime:
bhyve? Already mature enough?
or
VirtualBox?
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread adrian (Adrian Chadd)

adrian added inline comments.

INLINE COMMENTS
  sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c:455 this should be a separate 
commit

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin
Cc: freebsd-virtualization-list, freebsd-net-list
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: AMD CPUs

2016-02-04 Thread Dustin Marquess

I'm using bhyve on my AMD box because of this exact reason.  It's
working well enough for me!

-Dustin

On Thu, Feb 4, 2016 at 11:00 AM, Gerd Hafenbrack
 wrote:
> On 2016-02-04 13:21, Roger Pau Monné wrote:
>> El 4/2/16 a les 11:59, Gerd Hafenbrack ha escrit:
>>> Hello,
>>>
>>> I read on http://wiki.xen.org/wiki/FreeBSD_Dom0 the following:
 ... to run a FreeBSD PVH Dom0 an Intel box with EPT and a working IOMMU is 
 required.
>>>
>>> Why only intel and not an AMD CPU with Rapid Virtualization Indexing
>>> (RVI) and IOMMU as well?
>>
>> There's no technical reason on why this was done this way. It's just
>> that the original PVH implementation inside of Xen was badly designed,
>> and one of the results is the lack of support on AMD hardware. This is
>> not related to FreeBSD at all, Linux has the same exact problem.
>>
>> I'm (together with other people) currently working on removing this (and
>> other) stupid limitation by doing a proper implementation of PVH inside
>> of Xen. This new implementation is ATM called HVMlite. Sadly I can not
>> yet provide an ETA on when this is going to be finished. Once HVMlite is
>> finished inside of Xen FreeBSD will hopefully be able to run on AMD
>> hardware just like it does on Intel one. I will do a HEADS UP once this
>> is in testing state.
>>
>> Roger.
>
> Thx.
>
> I have to use an AMD box.
>
> In the meantime:
> bhyve? Already mature enough?
> or
> VirtualBox?
> ___
> freebsd-virtualization@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscr...@freebsd.org"
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

[Differential] [Request, 117 lines] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread sepherosa_gmail.com (Sepherosa Ziehau)

sepherosa_gmail.com created this revision.
sepherosa_gmail.com added reviewers: network, adrian, delphij, royger, 
decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, gallatin, 
hselasky, np.
sepherosa_gmail.com added subscribers: freebsd-net-list, 
freebsd-virtualization-list.
Herald added a reviewer: transport.

REVISION SUMMARY
  It's append_cnt based.  Unless the network driver sets these two limits, its 
an NO-OP.
  
  For hn(4):
  
  - Set TCP ACK append limit to 1, i.e. aggregate 2 ACKs at most.  Aggregate 
anything more than 2 hurts TCP sending performance in hyperv.  This 
significantly improves the TCP sending performance when the number of 
concurrent connetion is low (2~8).  And greatly stabilize the TCP sending 
performance in other cases.
  - Set TCP data segments append limit to 25.  Without this limitation, hn(4) 
could aggregate ~45 TCP data segments for each connection (even at 64 or more 
connections) before dispatching them to socket code; large aggregation slows 
down ACK sending and eventually hurts/destabilizes TCP reception performance.  
This setting stabilizes and improves TCP reception performance for >4 
concurrent connections significantly.
  
  Make them sysctls so they could be adjusted.

REVISION DETAIL
  https://reviews.freebsd.org/D5185

AFFECTED FILES
  sys/dev/hyperv/netvsc/hv_net_vsc.h
  sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
  sys/netinet/tcp_lro.c
  sys/netinet/tcp_lro.h

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, transport, adrian, delphij, royger, 
decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, gallatin, 
hselasky, np
Cc: freebsd-virtualization-list, freebsd-net-list
diff --git a/sys/netinet/tcp_lro.h b/sys/netinet/tcp_lro.h
--- a/sys/netinet/tcp_lro.h
+++ b/sys/netinet/tcp_lro.h
@@ -91,6 +91,8 @@
 	unsigned	lro_cnt;
 	unsigned	lro_mbuf_count;
 	unsigned	lro_mbuf_max;
+	unsigned short	lro_ack_append_lim;
+	unsigned short	lro_data_append_lim;
 
 	struct lro_head	lro_active;
 	struct lro_head	lro_free;
diff --git a/sys/netinet/tcp_lro.c b/sys/netinet/tcp_lro.c
--- a/sys/netinet/tcp_lro.c
+++ b/sys/netinet/tcp_lro.c
@@ -88,6 +88,8 @@
 	lc->lro_mbuf_max = lro_mbufs;
 	lc->lro_cnt = lro_entries;
 	lc->ifp = ifp;
+	lc->lro_ack_append_lim = 0;
+	lc->lro_data_append_lim = 0;
 	SLIST_INIT(>lro_free);
 	SLIST_INIT(>lro_active);
 
@@ -646,6 +648,16 @@
 
 		if (tcp_data_len == 0) {
 			m_freem(m);
+			/*
+			 * Flush this LRO entry, if this ACK should
+			 * not be further delayed.
+			 */
+			if (lc->lro_ack_append_lim &&
+			le->append_cnt >= lc->lro_ack_append_lim) {
+SLIST_REMOVE(>lro_active, le, lro_entry,
+next);
+tcp_lro_flush(lc, le);
+			}
 			return (0);
 		}
 
@@ -664,9 +676,12 @@
 
 		/*
 		 * If a possible next full length packet would cause an
-		 * overflow, pro-actively flush now.
+		 * overflow, pro-actively flush now.  And if we are asked
+		 * to limit the data aggregate, flush this LRO entry now.
 		 */
-		if (le->p_len > (65535 - lc->ifp->if_mtu)) {
+		if (le->p_len > (65535 - lc->ifp->if_mtu) ||
+		(lc->lro_data_append_lim &&
+		 le->append_cnt >= lc->lro_data_append_lim)) {
 			SLIST_REMOVE(>lro_active, le, lro_entry, next);
 			tcp_lro_flush(lc, le);
 		} else
diff --git a/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c b/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
--- a/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
+++ b/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
@@ -176,14 +176,8 @@
 #define HN_CSUM_ASSIST_WIN8	(CSUM_TCP)
 #define HN_CSUM_ASSIST		(CSUM_IP | CSUM_UDP | CSUM_TCP)
 
-/* XXX move to netinet/tcp_lro.h */
-#define HN_LRO_HIWAT_MAX65535
-#define HN_LRO_HIWAT_DEFHN_LRO_HIWAT_MAX
-/* YYY 2*MTU is a bit rough, but should be good enough. */
-#define HN_LRO_HIWAT_MTULIM(ifp)			(2 * (ifp)->if_mtu)
-#define HN_LRO_HIWAT_ISVALID(sc, hiwat)			\
-((hiwat) >= HN_LRO_HIWAT_MTULIM((sc)->hn_ifp) ||	\
- (hiwat) <= HN_LRO_HIWAT_MAX)
+#define HN_LRO_ACK_APPEND_LIM	1
+#define HN_LRO_DATA_APPEND_LIM	25
 
 /*
  * Be aware that this sleepable mutex will exhibit WITNESS errors when
@@ -253,27 +247,16 @@
 static void hn_start_txeof(struct ifnet *ifp);
 static int hn_ifmedia_upd(struct ifnet *ifp);
 static void hn_ifmedia_sts(struct ifnet *ifp, struct ifmediareq *ifmr);
-#ifdef HN_LRO_HIWAT
-static int hn_lro_hiwat_sysctl(SYSCTL_HANDLER_ARGS);
-#endif
 static int hn_trust_hcsum_sysctl(SYSCTL_HANDLER_ARGS);
 static int hn_tx_chimney_size_sysctl(SYSCTL_HANDLER_ARGS);
+static int hn_lro_append_lim_sysctl(SYSCTL_HANDLER_ARGS);
 static int hn_check_iplen(const struct mbuf *, int);
 static int hn_create_tx_ring(struct hn_softc *sc);
 static void hn_destroy_tx_ring(struct hn_softc *sc);
 static void hn_start_taskfunc(void *xsc, int pending);
 static void hn_txeof_taskfunc(void *xsc, int pending);
 static int hn_encap(struct hn_softc *, struct hn_txdesc *, struct mbuf **);
 
-static __inline void

[Differential] [Updated] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread sepherosa_gmail.com (Sepherosa Ziehau)

sepherosa_gmail.com updated the summary for this revision.

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, gallatin, hselasky, np, transport
Cc: freebsd-virtualization-list, freebsd-net-list
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

RE: Hyper-V networking: problem after upgrade to 10.2

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

[Differential] [Closed] D5175: hyperv/hn: Add an option to always do transmission scheduling

[Differential] [Updated] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

Re: AMD CPUs

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

Re: AMD CPUs

[Differential] [Request, 117 lines] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

[Differential] [Updated] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

10 matches

Site Navigation

Mail list logo

Footer information