Re: Can net.iflib.min_tx_latency=0 introduce an unbounded amount of latency?

On Sun, Mar 22, 2020 at 2:31 PM Ryan Stone wrote: > I've been tracking down a bug at work that appears to be due to > excessive latency introduced on the TX side of a TCP connection. In > looking through the iflib code, I noticed the tunable > net.iflib.min_tx_latency. My reading of the iflib

Re: terrible if_vmx / vmxnet3 rx performance with lro (post iflib)

On Mon, Feb 24, 2020 at 11:40 PM Patrick Kelsey wrote: > > > On Thu, Feb 20, 2020 at 4:58 PM Josh Paetzel wrote: > >> >> >> On Wed, Feb 19, 2020, at 7:17 AM, Andriy Gapon wrote: >> > On 18/02/2020 16:09, Andriy Gapon wrote: >> > > My general

Re: terrible if_vmx / vmxnet3 rx performance with lro (post iflib)

On Thu, Feb 20, 2020 at 4:58 PM Josh Paetzel wrote: > > > On Wed, Feb 19, 2020, at 7:17 AM, Andriy Gapon wrote: > > On 18/02/2020 16:09, Andriy Gapon wrote: > > > My general experience with post-iflib vmxnet3 is that vmxnet3 has some > > > peculiarities that result in a certain "impedance

Re: vmx: strange issue, related to to tso?

On Sun, Dec 29, 2019 at 6:06 AM Andriy Gapon wrote: > On 28/12/2019 06:43, Patrick Kelsey wrote: > > I am not able to test this at the moment, nor likely in the very near > future, > > but I did have a few minutes to do some code reading and now believe > that the

Re: vmx: strange issue, related to to tso?

s, > Vincenzo > >> Il giorno sab 28 dic 2019 alle ore 05:44 Patrick Kelsey >> ha scritto: >> >>> On Fri, Dec 27, 2019 at 5:01 PM Andriy Gapon wrote: >>> On 27/12/2019 15:34, Vincenzo Maffione wrote: >>> > It may be useful to

Re: vmx: strange issue, related to to tso?

On Fri, Dec 27, 2019 at 5:01 PM Andriy Gapon wrote: > On 27/12/2019 15:34, Vincenzo Maffione wrote: > > It may be useful to check what happens if you replace the vmx0 interface > with an > > em0. > > In this way you would know if the issue is vmx-specific or not. > > I'll put this on my to-do,

Re: vmx0: watchdog timeout on queue 2, no interrupts on BSP

> On Jul 21, 2019, at 4:17 PM, Andriy Gapon wrote: > >> On 20/07/2019 20:08, Patrick Kelsey wrote: >> >> >> On Fri, Jul 19, 2019 at 10:07 AM Andriy Gapon > <mailto:a...@freebsd.org>> wrote: >> >> >>Recently we experienced

Re: vmx0: watchdog timeout on queue 2, no interrupts on BSP

On Fri, Jul 19, 2019 at 10:07 AM Andriy Gapon wrote: > > Recently we experienced a strange problem. > We noticed a lot of these messages in the logs: > vmx0: watchdog timeout on queue 2 > (always queue 2) > Also, we noticed that connections to some end points did not work at all > while others

Conversion of vmx(4) (VMXNET3) driver to iflib review posted

Hi, There's a patch that converts the existing vmx(4) driver to iflib available for testing/review at https://reviews.freebsd.org/D18761. Best, Patrick ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To

Review posted for higher-bandwidth altq

Hi, I just posted a review (https://reviews.freebsd.org/D16782) for a patch to upgrade pfctl(8) and the pf(4) ioctl interface to be able to deal properly with bandwidth parameters greater than 32 bits. It also updates the math in the token bucket regulator and the HFSC scheduler to work up to at

Re: TCP_FASTOPEN is absent in GENERIC

On Tue, Jan 31, 2017 at 10:53 AM, Sergey Matveychuk wrote: > Hi. > > Is there a strong reason for option TCP_FASTOPEN is absent in GENERIC > kernel? It's off by default anyway (net.inet.tcp.fastopen.enabled=0). > > Latest dns/bind* versions want it very much. > > The kernel

Re: TCP Fast Open (RFC7413) for FreeBSD

> On Sep 2, 2015, at 12:21 PM, Rui Paulo <rpa...@me.com> wrote: > >> On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote: >> >> >> >>>> On Sep 2, 2015, at 12:54 AM, Rui Paulo <rpa...@me.com> wrote: >>>> >

TCP Fast Open (RFC7413) for FreeBSD

Hi, About two weeks from now, I will be starting work on server-side TCP Fast Open (TFO) support for FreeBSD head and stable/10, with the intention of having patches up for review by November. This message is an attempt to uncover any existing work on TFO for FreeBSD, as the existence of such

Re: TCP Fast Open (RFC7413) for FreeBSD

> On Sep 2, 2015, at 12:54 AM, Rui Paulo <rpa...@me.com> wrote: > >> On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: >> Hi, >> >> About two weeks from now, I will be starting work on server-side TCP >> Fast >> Open (TFO) support fo

Re: Looking for input on locally patch tcpdump or merge in latest release from upstream?

: SHA512 Hi, Hiren, On 05/27/15 21:55, hiren panchasara wrote: On 05/28/15 at 12:40P, Patrick Kelsey wrote: Hi, I've had a patch for a capsicum-related issue in tcpdump sitting around since last September ( https://lists.freebsd.org/pipermail/freebsd-current/2014-September/05

Looking for input on locally patch tcpdump or merge in latest release from upstream?

Hi, I've had a patch for a capsicum-related issue in tcpdump sitting around since last September ( https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052049.html) that is still needed and that I want finally address in the tree (the patch was reviewed by rwatson@ and pjd@ back

Re: netisr observations

On Fri, Apr 11, 2014 at 2:48 AM, Adrian Chadd adr...@freebsd.org wrote: [snip] So, hm, the thing that comes to mind is the flowid. What's the various flowid's for flows? Are they all mapping to CPU 3 somehow The output of netstat -Q shows IP dispatch is set to default, which is direct

Re: netisr observations

On Fri, Apr 11, 2014 at 8:23 PM, hiren panchasara hiren.panchas...@gmail.com wrote: On Fri, Apr 11, 2014 at 11:30 AM, Patrick Kelsey kel...@ieee.org wrote: The output of netstat -Q shows IP dispatch is set to default, which is direct (NETISR_DISPATCH_DIRECT). That means each IP packet

[ieee80211] [patch] BPF taps not working for ieee80211 interfaces in monitor mode

Hi, A bug was introduced in r254082 that results in BPF taps never being enabled for ieee80211 interfaces that are in monitor mode. Before r254082, bpf_track() in sys/net80211/ieee80211_freebsd.c was identifying ieee80211 interfaces by checking to see if the value of the ifp-if_start pointer was