Do not allocate MJUM9BYTES clusters under any circumstances. Trying
to allocate them when the system is under memory pressure is
enormously expensive and stands a good chance of livelocking the
system if you try to allocate too many too quickly, even when
allocating with M_NOWAIT.
Honestly, suppo
On 21 Nov 2017, at 17:14, Catalin Salgau wrote:
Actually m_getm2() will always produce a chain for a size larger than
the page size, due to m_getjcl() being called with MJUMPAGESIZE every
time a large buffer is requested. The function could probably be
called
with MJUM9BYTES in this case, but t
On 20/11/2017 11:26 pm, Kristof Provost wrote:
> On 19 Nov 2017, at 19:49, Catalin Salgau wrote:
>
> I'm trying to address the limitation in (upstream) net/vblade that was
> brought up in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
> This is related to writes large
On 19 Nov 2017, at 19:49, Catalin Salgau wrote:
I'm trying to address the limitation in (upstream) net/vblade that was
brought up in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
This is related to writes larger than hw.pagesize but smaller than the
configured MTU with BPF.
I traced th
Hello,
I'm trying to address the limitation in (upstream) net/vblade that was
brought up in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
This is related to writes larger than hw.pagesize but smaller than the
configured MTU with BPF.
I traced this to sys/net/bpf.c where calls to bpfwrit