[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #27 from Michael Tuexen --- (In reply to slw from comment #24) Consider a client doing a connect() call followed by a send() call. The connect call triggers the three way handshake. Assume that the third

Re: [panic] netmap(4) and if_lagg(4)

Hi, This is supposed to work because of the emulated netmap adapter. By means of that, Netmap works on tap(4) interfaces if_bridge interfaces, epairs, etc. Have you tried those to see if that works? Maybe here the problem is that if_lagg is a "metadriver", which interacts in a bad way with the

[Differential] D9451: Constrain IPv6 interface routes to each FIB

This revision was automatically updated to reflect the committed changes. Closed by commit rS315458: Constrain IPv6 routes to single FIBs when net.add_addr_allfibs=0 (authored by asomers). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D9451?vs=26053=26359#toc REPOSITORY rS FreeBSD src

Re: Are ./valte-ctl and ./bridge friends or competitors?

Hi, ./bridge is a netmap application that implements a simple forwarder between two netmap ports (given as input arguments). I don't see any way to use that to let two bhyve VMs work together. It's an example application that shows you how fast a netmap application can be in forwarding packets

Re: [panic] netmap(4) and if_lagg(4)

Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 18:29 (localtime): > Hi, > This is supposed to work because of the emulated netmap adapter. > By means of that, Netmap works on tap(4) interfaces if_bridge > interfaces, epairs, etc. Have you tried those to see if that works? Hello

[Bug 217871] SLAAC on a newly created epair sometimes fails to add routes

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 Conrad Meyer changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

Re: [panic] netmap(4) and if_lagg(4)

Two things here: - We pushed an important fix to stable/11 1-2 months ago, that prevents panic on emulated netmap mode. Maybe you are still getting that panic because you are using an older stable/11 image, you should check. - If you are using "software devices" like if_lagg or even vlan

[Bug 217862] ixgbe broken after 315333

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217862 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: erj Date: Fri Mar 17 21:24:10 UTC 2017 New revision: 315463 URL: https://svnweb.freebsd.org/changeset/base/315463 Log: ixgbe(4): Fix build breakage

Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530

On Fri, Mar 17, 2017 at 03:21:37PM -0400, John Jasen wrote: > On 03/17/2017 06:08 AM, Slawa Olhovchenkov wrote: > > > On Thu, Mar 16, 2017 at 03:50:42PM -0400, John Jasen wrote: > > > >> As a few points of note, partial resolution, and curiosity: > >> > >> Following down leads that 11-STABLE had

Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530

On Fri, Mar 17, 2017 at 12:21 PM, John Jasen wrote: > On 03/17/2017 06:08 AM, Slawa Olhovchenkov wrote: > >> On Thu, Mar 16, 2017 at 03:50:42PM -0400, John Jasen wrote: >> >>> As a few points of note, partial resolution, and curiosity: >>> >>> Following down leads that 11-STABLE

[Bug 217862] ixgbe broken after 315333

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217862 Conrad Meyer changed: What|Removed |Added CC||e...@freebsd.org,

Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530

On 03/17/2017 06:08 AM, Slawa Olhovchenkov wrote: > On Thu, Mar 16, 2017 at 03:50:42PM -0400, John Jasen wrote: > >> As a few points of note, partial resolution, and curiosity: >> >> Following down leads that 11-STABLE had tryforward improvements over >> 11-RELENG, I upgraded. The same tests (24

Re: Are ./valte-ctl and ./bridge friends or competitors?

On Fri, Mar 17, 2017 at 6:51 PM, Vincenzo Maffione wrote: > > When using your physical NICs with netmap, you need to disable the > offloadings because netmap is not able to program the NIC to perform these > offloadings. This is a design decision that has been taken to

[Bug 217871] SLAAC on a newly created epair sometimes fails to add routes

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 --- Comment #2 from Alan Somers --- Created attachment 180917 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180917=edit Patch for the slaac_on_nondefault_fib6 testcase -- You are receiving this mail

[Bug 217871] SLAAC on a newly created epair sometimes fails to add routes

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217871 --- Comment #1 from Alan Somers --- The problem seems to be that if you destroy an epair and then recreate it within about 60s, the SLAAC address from the previous (destroyed) interface gets assigned to the newly

Filtering multicast and/or 6to4?

After all these years, I'm still not 100% sure I understand multicast and 6to4. I'm trying to figure out when/why/if I should be filtering stuff, and in which direction(s). Is this the correct list to ask these sorts of questions? ___

Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530

On 03/17/2017 03:32 PM, Navdeep Parhar wrote: > On Fri, Mar 17, 2017 at 12:21 PM, John Jasen wrote: >> Yes. >> We were hopeful, initially, to be able to achieve higher packet >> forwarding rates through either netmap-fwd or due to enhancements based >> off

Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530

On Fri, Mar 17, 2017 at 11:43:32PM -0400, John Jasen wrote: > On 03/17/2017 03:32 PM, Navdeep Parhar wrote: > > > On Fri, Mar 17, 2017 at 12:21 PM, John Jasen wrote: > >> Yes. > >> We were hopeful, initially, to be able to achieve higher packet > >> forwarding rates through

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 18:51 (localtime): > Hi, > > ./bridge is a netmap application that implements a simple forwarder > between two netmap ports (given as input arguments). I don't see any way > to use that to let two bhyve VMs work together. It's an example >

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #22 from Michael Tuexen --- (In reply to Sepherosa Ziehau from comment #21) > Hmm, do any OS's TCP stacks really send data along w/ the last ACK in the > 3-way handshake at all? Assume the the initial ACK

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #23 from Sepherosa Ziehau --- (In reply to Michael Tuexen from comment #22) Thank you for the explanation for the ACK w/ data. As for syncookie usage. If we use syncookie it probably means two things: -

Are ./valte-ctl and ./bridge friends or competitors?

Hello, I'm still having problems understanding netmap(4) and would highly appreciate brief help. I'm running stable/11. I'd like to replace if_bridge(4) with netmap(4), because virtio-net chops jumbu frames (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215737) and if_bridge(4) requires

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 s...@zxy.spb.ru changed: What|Removed |Added CC||s...@zxy.spb.ru --- Comment #24

Re: Are ./valte-ctl and ./bridge friends or competitors?

Bezüglich Harry Schmalzbauer's Nachricht vom 17.03.2017 10:06 (localtime): > Hello, > > I'm still having problems understanding netmap(4) and would highly > appreciate brief help. > > I'm running stable/11. I'd like to replace if_bridge(4) with netmap(4), > because virtio-net chops jumbu frames

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #26 from s...@zxy.spb.ru --- (In reply to Alexandre martins from comment #25) Ah, I see. Like server to early discard inpcb for this connection/do incorrect state transmission (need some like CLOSE_WAIT for 2msl, I mean). For

[panic] netmap(4) and if_lagg(4)

Unforutantely I can't use if_lagg(4) as physical vale interface: lagg0: flags=8843 metric 0 mtu 9000 options=6403b9 ether 96:07:e9:78:c6:ac

Re: bad throughput performance on multiple systems: Re: Fwd: Re: Disappointing packets-per-second performance results on a Dell,PE R530

On Thu, Mar 16, 2017 at 03:50:42PM -0400, John Jasen wrote: > As a few points of note, partial resolution, and curiosity: > > Following down leads that 11-STABLE had tryforward improvements over > 11-RELENG, I upgraded. The same tests (24 client streams over UDP with > small packets), the system

[Bug 217637] One TCP connection accepted TWO times

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 --- Comment #25 from Alexandre martins --- (In reply to slw from comment #24) In fact, the first ACK is replayed. -> SYN (seq 1) <- SYN/ACK (seq 80 ACK 1) -> ACK (seq 1 ACK 81) -> [DATA] (seq 1 ACK 81)

[Bug 217606] Bridge stops working after some days

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 --- Comment #11 from Aiko Barz --- I installed the latest firmware (17.5.10) on those Intel X520 10G cards today. Dell replied within 10 minutes(!) with a bootable ISO image, which was able to do those nasty firmware