i386 LINT-NOIP kernel fails to compile due to lio

[Ryan Stone]

Hi everyone,

I got the following error on a make tinderbox.  It only affects i386
for whatever reason; I haven't debug into why:

linking kernel
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: error: undefined symbol: tcp_lro_flush_all
>>> referenced by lio_droq.c
>>>   lio_droq.o:(lio_droq_process_packets)

ld: error: undefined symbol: tcp_lro_rx
>>> referenced by lio_core.c
>>>   lio_core.o:(lio_push_packet)

ld: error: undefined symbol: tcp_lro_init
>>> referenced by lio_main.c
>>>   lio_main.o:(lio_attach)

ld: error: undefined symbol: tcp_lro_free
>>> referenced by lio_main.c
>>>   lio_main.o:(lio_attach)
>>> referenced by lio_main.c
>>>   lio_main.o:(lio_destroy_nic_device)
*** [kernel] Error code 1

make[2]: stopped in /usr/obj/srcpool/src/rstone/freebsd/i386.i386/sys/LINT-NOIP
1 error

make[2]: stopped in /usr/obj/srcpool/src/rstone/freebsd/i386.i386/sys/LINT-NOIP
  82.40 real  2242.85 user   279.16 sys

make[1]: stopped in /srcpool/src/rstone/freebsd

make: stopped in /srcpool/src/rstone/freebsd

Re: Chelsio cards, jumbo frames, memory fragmentation and performance in FreeBSD 13.x?

[Ryan Stone]

Set it to 4k and move on.  I'm not aware of any efforts in the VM
layer or network stack to make >PAGE_SIZE clusters usable in practical
situations.  Honestly, at this point I wish that we'd just kill them
entirely.

On Fri, Dec 3, 2021 at 12:52 PM John Jasen  wrote:
>
> Pretty close to two years ago, we tripped across conditions where heavily
> used FreeBSD 11.x packet-filter firewalls would slow to a crawl and load
> would go crazy.
>
> In a fit of hopefulness with our upgrade to FreeBSD 13.0, I removed the
> hw.cxgbe.largest_rx_cluster settings we put in place -- only to have our
> hardest hit firewall experience high load and plummeting bandwidth within a
> few hours.
>
> So, I have two questions -- is there a better fix for this? Or, is the
> approach to set largest_rx_cluster to 4k and move on?
>
> Thanks in advance!

Re: Bug in MAC filter on IGB/if_vlan?

[Ryan Stone]

You're trying to use different MACs with each vlan.  I don't believe
that this is really a support configuration in our stack, although
putting the interface into promiscuous I guess works.

rip6_output not in net epoch across call to ip6_setpktopts()

[Ryan Stone]

Recently at work we saw a panic in ip6_setpktopt() while it's using an
ifnet returned by ifnet_byindex, here:

https://cgit.freebsd.org/src/tree/sys/netinet6/ip6_output.c#n2969

The issue seems to be that rip6_output() calls into ip6_setpktopts()
outside of the net epoch.  Should I just wrap the setpktopts call in a
net epoch enter/exit, or does anybody think that there's something
cleverer that should be done there?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ifaddr reference count leaks that seem to be related to routing code

[Ryan Stone]

On Fri, Feb 12, 2021 at 4:14 PM Alexander V. Chernikov
 wrote:
> The slightly different approach here: https://reviews.freebsd.org/D28629
> We indeed are running under epoch, so that prevents _immediate_ ifa 
> destruction.
> However, we still can run into the situation when
> * in thread 1 we drop to 0 refcount for ifa and schedule its deletion.
> * in thread 2 we use this ifa and reference it
> * destroy callout kicks in
> * unhappy user reports bug
> The current approach minimises this possibility by taking an ifa refcount 
> early.
> More general approach would probably be in introducing `ifa_try_ref()` based 
> on refcount_acquire_if_not_zero() but that's something that needs a bit more 
> effort.

Oops, you're completely correct.  Do you think that we should put a
KASSERT in ifa_ref() that ifa_refcnt > 0 to catch such a bug if
somebody ever manages to introduce one?  Of course it would not fire
except in the case where we already lost the race, but at least it
would make it easier to debug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ifaddr reference count leaks that seem to be related to routing code

[Ryan Stone]

Thanks!  For reference, I tried this patch and it did resolve my leak:

https://github.com/rysto32/freebsd/commit/73caa71c351c072d673d477972fda2aeb369eb3d

I haven't exhaustively tested the routing code, though, so I can't say
for certain that the assert will always be true, nor am I certain that
no callers were depending on ifa_ref by rt_getifa_fib().
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

ifaddr reference count leaks that seem to be related to routing code

[Ryan Stone]

On main I'm seeing leaks of ifaddr reference counts.  I can reproduce
this in a bhyve VM by repeating this:

   vlan=`ifconfig vlan create vlandev vtnet0 vlan 777`
   ifconfig $vlan up
   ifconfig $vlan 1.0.0.1/24
   ifconfig $vlan destroy

If I watch the ifaddr column of vmstat -m while I repeat this, I see
it increasing by one every time.  Poking around with dtrace confirms
that it's an AF_INET address that's getting leaked.  Looking at the
calls to ifa_ref and ifa_free, the routing code looks suspicious.  I
see that the route add path takes one reference here:

https://cgit.freebsd.org/src/tree/sys/net/route/route_ctl.c#n588

  kernel`rib_add_route+0x11e
  kernel`rib_handle_ifaddr_info+0xd7
  kernel`in_handle_ifaddr_route+0x1cd
  kernel`in_addprefix+0x18b
  kernel`in_control+0xada
  kernel`ifioctl+0x3d8
  kernel`kern_ioctl+0x289
  kernel`sys_ioctl+0x12a
  kernel`amd64_syscall+0x12e
  kernel`0x8108b9be

(for me directly in the else case, or rt_getifa_fib() will take one on
the ifa it grabs)

I see a second reference taken in the nhop code:
  kernel`get_nhop+0xd8
  kernel`nhop_create_from_info+0x1df
  kernel`rib_add_route+0x12e
  kernel`rib_handle_ifaddr_info+0xd7
  kernel`in_handle_ifaddr_route+0x1cd
  kernel`in_addprefix+0x18b
  kernel`in_control+0xada
  kernel`ifioctl+0x3d8
  kernel`kern_ioctl+0x289
  kernel`sys_ioctl+0x12a
  kernel`amd64_syscall+0x12e
  kernel`0x8108b9be

But I only see one reference released when the nhop is cleaned up:
  kernel`destroy_nhop_epoch+0x2d
  kernel`epoch_call_task+0x13a
  kernel`gtaskqueue_run_locked+0xa7
  kernel`gtaskqueue_thread_loop+0x94
  kernel`fork_exit+0x80
  kernel`0x8108c11e

It looks to me like we can either lose the ifa_ref() from
create_rtentry entirely (if the route add code runs within the
net_epoch), or we need to release that reference before returning from
rib_add_route().  Can somebody take a look at this and confirm my
findings?  Thanks
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: iflib tx watchdog doesn't appear that it can work anymore

[Ryan Stone]

So what's the plan with the iflib watchdog?  If it's not going to be
fixed, should it just be removed entirely?  I don't think that's a
great idea but I remember that the Intel watchdogs got a lot of
rototilling to try and get them right so I'm nervous about going in
and just trying to reimplement the watchdog myself.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: iflib tx watchdog doesn't appear that it can work anymore

[Ryan Stone]

We hit the bug of the watchdog firing on idle NICs and were working on
merging r356310 into our tree when we noticed the problem through code
inspection.  I don't think that it's really a bug with r356310, just a
latent one that has become exposed.

On Mon, Nov 9, 2020 at 2:48 PM Eric Joyner  wrote:
>
> I'll add Piotr, the author of your linked patch, to this thread.
>
> Are you seeing a problem connected to the watchdog? Piotr tells me that 
> IFLIB_QUEUE_WORKING isn't used now, but it wasn't even used before his patch.
>
> - Eric
>
> On Wed, Nov 4, 2020 at 8:47 AM Ryan Stone  wrote:
>>
>> https://svnweb.freebsd.org/base?view=revision=356310
>>
>> As of r356310, there does not appear to be a way that ift_qstatus can
>> be set to anything but IFLIB_QUEUE_IDLE.  As a result, I don't see
>> that there is any way for the watchdog to ever fire.
>>
>> I think that iflib has missed setting ift_qstatus to
>> IFLIB_QUEUE_WORKING when packets are enqueued on the rx ring.
>> ___
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

iflib tx watchdog doesn't appear that it can work anymore

[Ryan Stone]

https://svnweb.freebsd.org/base?view=revision=356310

As of r356310, there does not appear to be a way that ift_qstatus can
be set to anything but IFLIB_QUEUE_IDLE.  As a result, I don't see
that there is any way for the watchdog to ever fire.

I think that iflib has missed setting ift_qstatus to
IFLIB_QUEUE_WORKING when packets are enqueued on the rx ring.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Panic in in6_joingroup_locked

[Ryan Stone]

Today at $WORK we saw a panic due to a race between
in6_joingroup_locked and if_detach_internal.  This happened on a
branch that's about 2 years behind head, but the relevant code in head
does not appear to have changed.

The backtrace of the panic was this:

panic: Fatal trap 9: general protection fault while in kernel mode
Stack: --
kernel:trap_fatal+0x96
kernel:trap+0x76
kernel:in6_joingroup_locked+0x2c7
kernel:in6_joingroup+0x46
kernel:in6_update_ifa+0x18e5
kernel:in6_ifattach+0x4d0
kernel:in6_if_up+0x99
kernel:if_up+0x7d
kernel:ifhwioctl+0xcea
kernel:ifioctl+0x2c9
kernel:kern_ioctl+0x29b
kernel:sys_ioctl+0x16d
kernel:amd64_syscall+0x327

We panic'ed here, because the memory pointed to by ifma has been freed
and filled with 0xdeadc0de:

https://svnweb.freebsd.org/base/head/sys/netinet6/in6_mcast.c?revision=365071=markup#l421

Another thread was in the process of trying to destroy the same
interface.  It had the following backtrace at the time of the panic:

#0 sched_switch (td=0xfea654845aa0, newtd=0xfea266fa9aa0,
flags=) at /b/mnt/src/sys/kern/sched_ule.c:2423
#1 0x80643071 in mi_switch (flags=, newtd=0x0)
at /b/mnt/src/sys/kern/kern_synch.c:605
#2 0x80693234 in sleepq_switch (wchan=0x8139cc90
, pri=0) at /b/mnt/src/sys/kern/subr_sleepqueue.c:612
#3 0x806930c3 in sleepq_wait (wchan=0x8139cc90
, pri=0) at /b/mnt/src/sys/kern/subr_sleepqueue.c:691
#4 0x8063fcb3 in _sx_xlock_hard (sx=,
x=, opts=0, timo=0, file=,
line=) at
/b/mnt/src/sys/kern/kern_sx.c:936
#5 0x8063f313 in _sx_xlock (sx=0x8139cc90 ,
opts=0, timo=, file=0x80ba6d2a
"/b/mnt/src/sys/net/i
f_vlan.c", line=668) at /b/mnt/src/sys/kern/kern_sx.c:352
#6 0x807558b2 in vlan_ifdetach (arg=,
ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if_vlan.c:668
#7 0x80747676 in if_detach_internal (vmove=0, ifp=, ifcp=) at /b/mnt/src/sys/net/if.c:1203
#8 if_detach (ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if.c:1060
#9 0x80756521 in vlan_clone_destroy (ifc=0xf802f29dbe80,
ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if_vlan.c:1102
#10 0x8074dc57 in if_clone_destroyif (ifc=0xf802f29dbe80,
ifp=0xf8049b2ce000) at /b/mnt/src/sys/net/if_clone.c:330
#11 0x8074dafe in if_clone_destroy (name=) at
/b/mnt/src/sys/net/if_clone.c:288
#12 0x8074b2fd in ifioctl (so=0xfea6363806d0,
cmd=2149607801, data=, td=0xfea654845aa0) at
/b/mnt/src/sys/net/if.
c:3077
#13 0x806aab1c in fo_ioctl (fp=, com=, active_cred=, td=, data=
) at /b/mnt/src/sys/sys/file.h:396
#14 kern_ioctl (td=0xfea654845aa0, fd=4, com=,
data=) at /b/mnt/src/sys/kern/sys_generic.c:938
#15 0x806aa7fe in sys_ioctl (td=0xfea654845aa0,
uap=0xfea653441b30) at /b/mnt/src/sys/kern/sys_generic.c:846
#16 0x809ceab8 in syscallenter (td=) at
/b/mnt/src/sys/amd64/amd64/../../kern/subr_syscall.c:187
#17 amd64_syscall (td=0xfea654845aa0, traced=0) at
/b/mnt/src/sys/amd64/amd64/trap.c:1196
#18 fast_syscall_common () at /b/mnt/src/sys/amd64/amd64/exception.S:505

Frame 7 was at this point in if_detach_internal

https://svnweb.freebsd.org/base/head/sys/net/if.c?revision=366230=markup#l1206

As you can see, a couple of lines up if_purgemaddrs() was called and
freed all multicast addresses assigned to the interface, which
destroyed the multicast address being added out from under
in6_joingroup_locked.

I see two potential paths forward: either the wacky locking in
in6_getmulti() gets fixed so that we don't have to do the "drop the
lock to call a function that acquires that lock again" dance that
opens up this race condition, or we fix if_addmulti so that it adds an
additional reference to the address if retifma is non-NULL.

The second option would be a KPI change that would have a nasty side
effect of leaking the address if an existing caller wasn't fixed, but
on the other hand the current interface seems pretty useless if it
can't actually guarantee that the address you asked for will exist
when you get around to trying to manipulate it.

Does anybody have any thoughts on this?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: safe_pause_us() is always at least 1 millisecond long

[Ryan Stone]

Using min is definitely not correct.  That would ensure that you
either got a pause of 1 tick or 0 ticks.

This may get you better granularity, depending on the system.

pause_sbt("e1000_delay", x * SBT_1US, x < 1000 ? 100 * SBT_1US : SBT_1MS, 0);
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Socket option to configure Ethernet PCP / CoS per-flow

[Ryan Stone]

On Fri, Sep 11, 2020 at 12:33 PM Scheffenegger, Richard
 wrote:
>
> Hi,
>
> Currently, upstream head has only an IOCTL API to set up interface-wide 
> default PCP marking:
>
> #define  SIOCGVLANPCPSIOCGLANPCP /* Get VLAN PCP */
> #define   SIOCSVLANPCPSIOCSLANPCP  /* Set VLAN PCP */
>
> And the interface is via ifconfig  pcp .
>
> However, while this allows all traffic sent via a specific interface to be 
> marked with a PCP (priority code point), it defeats the purpose of PFC 
> (priority flow control) which works by individually pausing different queues 
> of an interface, provided there is an actual differentiation of traffic into 
> those various classes.
>
> Internally, we have added a socket option (SO_VLAN_PCP) to change the PCP 
> specifically for traffic associated with that socket, to be marked 
> differently from whatever the interface default is (unmarked, or the default 
> PCP).
>
> Does the community see value in having such a socket option widely available? 
> (Linux currently doesn't seem to have a per-socket option either, only a 
> per-interface IOCTL API).
>
> Best regards,
>
> Richard Scheffenegger
>
> ___
> freebsd-transp...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-transport
> To unsubscribe, send any mail to "freebsd-transport-unsubscr...@freebsd.org"

Hi Richard,

At $WORK we're running into situations where PFC support would be very
useful, so I think that this would be a good thing to add.  I have a
question: does your work also communicate the priority value for an
mbuf down to the Ethernet driver, so that it can put the packet in the
proper queue?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Is anybody using ng_pipe?

[Ryan Stone]

On Tue, Aug 18, 2020 at 5:43 PM Marko Zec  wrote:
> Since in ng_pipe we define BER as an one error in BER bits (integer
> value), wouldn't your formula P = 1 - BER yield results less than or
> equal to zero for all non-zero values of BER?  The domain of P is
> [0..1], so that won't fly.
>
> Your analysis seems to be based on an assumption that the BER
> parameter is given as a multiplier to 0.5**48, which it is not.
>
> The proper fix would be to clarify the current BER parameter semantics
> in ng_pipe(4), not to break bridges with the existing scripts / software
> which rely on ng_pipe.
>
> Cheers,
>
> Marko

The manpage defined the BER parameter as follows:

u_int64_t  ber; /* errors per 2^48 bits */

If we instead want to change the documentation to match the
implementation, that's fine too.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Is anybody using ng_pipe?

[Ryan Stone]

On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein  wrote:
> Sorry, missed that. But why wasn't possible?

There's a daemon running on the system that handles most network
configuration.  It's quite inflexible and will override any manual
configuration changes.  It manages firewall rules but is ignorant of
netgraph, so it will remove any dummynet rules but leave netgraph
configuration alone.  It was significantly easier to just use ng_pipe,
even after having to fix or work around the bugs, than it was to fight
the daemon.

On Tue, Aug 18, 2020 at 2:56 PM Marko Zec  wrote:
> The probability that a frame is completely unaffected by BER events,
> and thus shouldn't be dropped, is currently computed as
>
> Ppass(BER, plen) = Psingle_bit_unaffected(BER) ^ Nbits(plen)

The problem is in its calculation of Psingle_bit_unaffected(BER).  The
BER is the fraction of bits that are affected, therefore it is the
probability that a bit is affected.  But for some reason,
Psingle_bit_unaffected(BER) is calculated as 1 - 1/BER rather than 1 -
BER.  This leads to the probability table being wrong.  For example,
given a BER of 2350, the probability that a 1500-byte packet is
not dropped is:

(1 - 2350/2**48)**(1500 * 8), which is approximately 99.00%.

However, ng_pipe calculates a fixed-point probability value of
281460603879001.  To calculate whether a frame should be dropped,
ng_pipe takes this probability value and shifts it right by 17,
yielding 2147373991.  It then calls rand() to generate a random number
in the range [0,2**31-1]; if the random number is larger than the
probability value than it is dropped, otherwise it is kept.  The
chances that a packet is kept is therefore 2147373991/(2**31 - 1), or
about 99.99%.

It's easy enough to fix this one, but I wasn't sure that it would be
so easy to fix the TSO/LRO issue without significantly increasing the
memory usage, so I wanted to gauge whether it was worth pursuing that
avenue or if a simpler model would be a better use of my time.  The
feedback is definitely that a simpler model is *not* warranted, so
let's talk about fixing TSO/LRO.

On Tue, Aug 18, 2020 at 1:47 PM Rodney W. Grimes
 wrote:
> Hum, that sounds like a poor implementation indeed.  It seems
> like it would be easy to convert a BER into a packet drop
> probability based on bytes that have passed through the pipe.

I'm not quite following you; can you elaborate?  Would this solution
require us to update some shared state between each packet?  One
advantage of the current approach is that there is no mutable state
(except, of course, when configuration changes).
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Is anybody using ng_pipe?

[Ryan Stone]

On Tue, Aug 18, 2020 at 1:17 PM Ryan Stone  wrote:
> 4. The table calculation had two integer truncation bugs and used the
> wrong formula.  I'm reasonably sure it would never calculate a
> probability other than 0 due a 64-bit constant being truncated to
> 32-bits.

I've gone back and checked, and I was partially wrong on this point.
I had gotten the idea that integer literals would be truncated to int,
which is not true.  The use of the wrong formula still means that
packets are dropped at entirely the wrong rate, though.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Is anybody using ng_pipe?

[Ryan Stone]

I recently needed to be able to simulate a lossy, high-latency network
in an environment where dummynet wasn't possible.  I gave ng_pipe a
try, and hit some major issues

1. Instead of configuring a packet drop rate, you configure a bit
error rate, which I found significantly less intuitive
2. The use of BER makes for a very inconvenient implementation, as
ng_pipe has to maintain a table of packet drop rates for every
possible packet size
3. The table implementation isn't sized right for LRO or TSO, leading
to ng_pipe going out of bounds of the array and panicking the system
4. The table calculation had two integer truncation bugs and used the
wrong formula.  I'm reasonably sure it would never calculate a
probability other than 0 due a 64-bit constant being truncated to
32-bits.

I'd like to dump all of this and just implement a packet loss rate,
which would simplify all this immensely.  Is anybody using ng_pipe
with a non-zero BER who would object to this?  Given this litany of
issues I doubt it, but I thought that I'd be sure.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

ndp -P => panic: prefix 0xfffff80011c56700 has referencing addresses

[Ryan Stone]

# ifconfig vtnet0 inet6 1::1
# ndp -P
panic: prefix 0xf80011c56700 has referencing addresses
cpuid = 1
time = 1591991817
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0022d08720
vpanic() at vpanic+0x19d/frame 0xfe0022d08770
panic() at panic+0x43/frame 0xfe0022d087d0
nd6_prefix_del() at nd6_prefix_del+0x1e7/frame 0xfe0022d08840
nd6_ioctl() at nd6_ioctl+0x5a8/frame 0xfe0022d088c0
ifioctl() at ifioctl+0x574/frame 0xfe0022d08990
kern_ioctl() at kern_ioctl+0x295/frame 0xfe0022d089f0
sys_ioctl() at sys_ioctl+0x15d/frame 0xfe0022d08ac0
amd64_syscall() at amd64_syscall+0x2b9/frame 0xfe0022d08bf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0022d08bf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80041929a, rsp =
0x7fffe748, rbp = 0x7fffec00 ---

Looking at the code handling the SIOCSPFXFLUSH_IN6 ioctl(), it's clear
that it's just trying to free every nd_prefix (excepting link-local
prefixes), but what's less clear to me is what this should do instead.
Should this only flush prefixes learned through NDP RAs?  What do we
do if a non-autoconf address is assigned from such a prefix?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[Ryan Stone]

Thanks for the analysis.  I haven't had much of an opportunity to get
into the guts of iflib and I'm not very successful at following the
round trips through mpring yet.

On Mon, Mar 23, 2020 at 12:50 AM Patrick Kelsey  wrote:
>
>
>
> 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 code is that if a
>> packet is enqueued to a tx ring but not posted (when
>> min_tx_latency=0), then iflib can introduce an unbounded amount of
>> latency if the ring is idle.  Is my reading of the code correct?
>>
>
> Let's see...in the case described above, the next iflib_timer() invocation 
> (max 500ms later) should find that txq->ift_db_pending is non-zero, which 
> will cause it to enqueue the TX task, which will invoke _task_fn_tx(), which 
> will then enqueue the special marker (void **), and one way or another, 
> iflib_txq_drain() will be called.
>
> Looking at iflib_txq_drain() it appears that the first call to 
> iflib_txd_db_check() should post the pending packets either because a 
> non-zero number of slots were just reclaimed, or the check for 
> txq->ift_db_pending >= TXQ_MAX_DB_DEFERRED(...) is satisfied, unless there 
> are too many posted packets in the hardware queue that aren't being drained 
> by the hardware (this would result in the in_use parameter remaining elevated 
> such that a small number of pending packets would not exceed the threshold, 
> and also no slot reclaim occurring).
>
> -Patrick
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[Ryan Stone]

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 code is that if a
packet is enqueued to a tx ring but not posted (when
min_tx_latency=0), then iflib can introduce an unbounded amount of
latency if the ring is idle.  Is my reading of the code correct?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IPv6: Invalid nd6 entry created for an RA without an lladdr

[Ryan Stone]

Ah, that’s my mistake. I originally saw the issue on an older FreeBSD release 
and missed that the code had changed subtly when I looked up the version in 
head. r328552 fixed this issue already

Thanks for the sanity check. 

Sent from my iPhone

> On Oct 2, 2019, at 6:51 PM, 神明達哉  wrote:
> 
> At Wed, 2 Oct 2019 17:04:23 -0400,
> Ryan Stone  wrote:
> > 
> > At work, our product is putting through an IPv6 conformance test and
> > it's found an issue in our handling of Routing Advertisements (RAs).
> > If we receive an RA that does not specify an lladdr, then
> > nd6_cache_lladdr() is called with lladdr NULL:
> > 
> > https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c?revision=347984=markup#l1961
> > 
> > In this case, the linkhdr cache is never initialized, but we still put
> > the entry in the STALE state at line 2032.
> 
> If lladdr is NULL shouldn't it reach line 2032?
> 
> if (lladdr != NULL) { /* (7) */
> nd6_llinfo_setstate(ln, ND6_LLINFO_STALE);
> EVENTHANDLER_INVOKE(lle_event, ln,
>LLENTRY_RESOLVED);
> }
> 
> In any case, if a host receives an RA without a link-layer address
> option and no neighbor cache entry exists for the RA sender at that
> point, it shouldn't set the state of a newly created cache entry to
> STALE.  While RFC4861 is not so explicit about this particular
> condition, I believe it's pretty clear from Section 6.3.4 of the RFC
> (it may even be questionable just to create an entry in this case, but
> that's probably within the scope of acceptable implementation choices
> as long as the entry is a mere placeholder).  I also believe FreeBSD
> used to not do this (correctly), so if it currently sets it to STALE
> it's quite likely to be some regression.
> 
> --
> JINMEI, Tatuya
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

IPv6: Invalid nd6 entry created for an RA without an lladdr

[Ryan Stone]

At work, our product is putting through an IPv6 conformance test and
it's found an issue in our handling of Routing Advertisements (RAs).
If we receive an RA that does not specify an lladdr, then
nd6_cache_lladdr() is called with lladdr NULL:

https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c?revision=347984=markup#l1961

In this case, the linkhdr cache is never initialized, but we still put
the entry in the STALE state at line 2032.

Because the entry is in the STALE state, nd6_resolve_slow() will
happily return the uninitialized data to callers, causing us to send
packets with a garbage link-layer header:

https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c?revision=347984=markup#l2410


I'm unsure what the standard says is the right behaviour in this
situation and before I start digging through RFCs, I was wondering if
anybody knew what the right thing to do is.  I've played with not
putting the nd6 entry into the STALE state if we don't have an lladdr,
and while it seems to work I'm unsure if it's the right thing to do.


If people are curious, the RA-handling code that calls into
nd6_cache_lladdr can be found here:

https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_rtr.c?revision=348121=markup#l185
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: BBR patches?

[Ryan Stone]

rrs@ has just posted the BBR patch to phabricator:

https://reviews.freebsd.org/D21582
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: udp_notify() invalidates the routing cache without a write lock

[Ryan Stone]

I have put a CR up on phab for this:

https://reviews.freebsd.org/D17246
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Fwd: Status of 10.4 fixes for CVE-2018-6923 (Fragment Stack)

[Ryan Stone]

I didn't get a response to this, so I'm forwarding to a higher-traffic
list.  Does anybody know if there is work in progress on a for for
stable/10?

-- Forwarded message -
From: Ryan Stone 
Date: Tue, Sep 11, 2018 at 2:37 PM
Subject: Status of 10.4 fixes for CVE-2018-6923 (Fragment Stack)
To:  


In the security advisory for CVE-2018-6923, it says that fixes for
10.4 are forthcoming.  They don't seem to have landed in the tree yet.
We're going to need to ship a 10.x fix for $WORK and I'd like to know
if we need to implement the fix ourselves or if the patch is in the
works already.

Thanks,
Ryan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

udp_notify() invalidates the routing cache without a write lock

[Ryan Stone]

Recently at work I had a system crash while executing RTFREE() in
udp_notify().  In looking at the system I discovered that two threads
had called udp_notify() on the same pcb.  This was possible because
the threads only held a read lock on the socket.  The obvious solution
is to hold a write lock in this path.  I haven't even compile-tested
the patch below yet, but would anybody have any objections to this
approach?

diff --git a/sys/netinet/udp_usrreq.c b/sys/netinet/udp_usrreq.c
index cae044c066c3..429f195ee954 100644
--- a/sys/netinet/udp_usrreq.c
+++ b/sys/netinet/udp_usrreq.c
@@ -756,13 +756,7 @@ struct inpcb *
udp_notify(struct inpcb *inp, int errno)
{

-   /*
-* While udp_ctlinput() always calls udp_notify() with a read lock
-* when invoking it directly, in_pcbnotifyall() currently uses write
-* locks due to sharing code with TCP.  For now, accept either a read
-* or a write lock, but a read lock is sufficient.
-*/
-   INP_LOCK_ASSERT(inp);
+   INP_WLOCK_ASSERT(inp);
   if ((errno == EHOSTUNREACH || errno == ENETUNREACH ||
errno == EHOSTDOWN) && inp->inp_route.ro_rt) {
   RTFREE(inp->inp_route.ro_rt);
@@ -808,13 +802,13 @@ udp_common_ctlinput(int cmd, struct sockaddr
*sa, void *vip,
   if (ip != NULL) {
   uh = (struct udphdr *)((caddr_t)ip + (ip->ip_hl << 2));
   inp = in_pcblookup(pcbinfo, faddr, uh->uh_dport,
-   ip->ip_src, uh->uh_sport, INPLOOKUP_RLOCKPCB, NULL);
+   ip->ip_src, uh->uh_sport, INPLOOKUP_WLOCKPCB, NULL);
   if (inp != NULL) {
-   INP_RLOCK_ASSERT(inp);
+   INP_WLOCK_ASSERT(inp);
   if (inp->inp_socket != NULL) {
   udp_notify(inp, inetctlerrmap[cmd]);
   }
-   INP_RUNLOCK(inp);
+   INP_WUNLOCK(inp);
   } else {
   inp = in_pcblookup(pcbinfo, faddr, uh->uh_dport,
  ip->ip_src, uh->uh_sport,
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Testing VF/PF code

[Ryan Stone]

On Tue, May 29, 2018 at 12:58 PM Sean Bruno  wrote:
>
> Does anyone have a process for testing the VF drivers (ixgbe igb, etc)
> in FreeBSD without actually firing up linux to instantiate a VM or using
> EC2?

We have native support for creating VFs for ixl and ixgbe (and cxgbe).
For igb you're out of luck (but SR-IOV on igb is kind of a waste of
time anyway)

To create the VFs, create the following conf file:

ix0.conf:

PF {
device : "ix0";
num_vfs : 4;
 }


You can create the VFs with "iovctl -f ix0.conf -C"

You should see 4 new ixgbevf instances show up in the PCI tree and the
driver should attach.  The one caveat here is that I'm not sure of the
state of the ixgbe PF implementation -- some people reported issues
with it a while back, and I'm not sure if they were ever resolved.
ixl should be solid, though.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mlx5(4) jumbo receive

[Ryan Stone]

On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov
 wrote:
> +#ifndef MLX5E_MAX_RX_BYTES
> +#defineMLX5E_MAX_RX_BYTES MCLBYTES
> +#endif

Why do you use a 2KB buffer rather than a PAGE_SIZE'd buffer?
MJUMPAGESIZE should offer significantly better performance for jumbo
frames without increasing the risk of memory fragmentation.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Cisco shows LACP not enabled on 11.1U2, BCM 57810S-t, 2960X IOS 15.2

[Ryan Stone]

Unfortunately, this is a known issue with the bxe driver.  I was under
the impression that QLogic had committed a fix to -head, but I just
checked and it hasn't seen any updates from QLogic in over a year,
unfortunately.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[PATCH] Fix for IPv4 subnet route migration

[Ryan Stone]

Currently, the FreeBSD stack gets itself into a bizarre state if you
try to change the source IP for a subnet route (yes, this implies
using two IPs on the same subnet on a system.  Yes, I'm aware this is
a Bad Idea(TM).  Unfortunately I have a customer that insists on this
configuration)

You can see the review description for all of the gory details.  IPv6
is not affected by the issue so I only had to fix IPv4.  The review is
here:

https://reviews.freebsd.org/D14547

If anybody is interested in reviewing this fix, please subscribe
yourself to the review.  Thanks!

Ryan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Review: Fix regression that did not allow "route change" that didn't re-specify the gateway

[Ryan Stone]

A change a while back (r264986) broke the ability to change a route's
parameters if the gateway wasn't explicitly specified again.  For
example, you used to be able to run "route change 10.0.0.0/8 -mtu
9000" to change the MTU without having to provide the gateway IP to
the command.  I have a review open to restore the existing behaviour.
In cases where the gateway is not specified, the gateway on the route
remains unchanged.

Anyone interested in reviewing this change should add themselves as a
reviewer to https://reviews.freebsd.org/D14291.

Thanks,
Ryan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

3 ARP cache related reviews

[Ryan Stone]

I've opened 3 phabricator reviews fixing issues with the inpcb llentry caching.

https://reviews.freebsd.org/D13988

This fix invalidates the llentry cache after the L3 route cache was
invalidated by the routing table's generation count incrementing.
Without this fix existing connections would continue to use stale L2
headers after the routing table was updated.  I tried a simple test
where I added a new route that would change the routing of an active
TCP connection and confirmed with tcpdump that without this fix, the
stack continues to use the old src/dst MAC for the original route.
This caused the traffic to be blackholed at the new gateway as the MAC
did not match.

https://reviews.freebsd.org/D13989

This is a simple cleanup of the inpcb cache invalidation.  Rather than
copy-and-pasting the separate invalidation of the L2 cache and the L3
cache, I move the invalidation into a single macro and invoke it
everywhere that needs to drop the cache.  This will hopefully prevent
future bugs like D13988 from occurring in new code.

https://reviews.freebsd.org/D13990

This fixes an issue where the inpcb L2 cache was not updated following
a change to a route's gateway.  This led the connection to continue to
use the old gateway.  If the old gateway stopping routing traffic this
would cause the connection to be blackholed.  My fix here is more
heavy-handed than it needs to be, as I just increment the route table
generation count, which will cause all connections to drop their L2
and L3 caches.  This could be made more selective by adding a
generation count to each route entry, but I don't believe that route
table modifications will happen frequently enough for anybody to care.
Please speak up if you believe differently.

If you're interested in one or more of these changes, please subscribe
yourself to the reviews.  I don't subscribe mailing lists to reviews
to reduce the spam on the lists.

Thanks,
Ryan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Allowing a local subnet route to change to a different ifnet

[Ryan Stone]

I'm going to prefix this question by noting that I realize that the
configuration that I am about to describe is quite nonsensical.
Unfortunately, it seems that under older versions of FreeBSD (possibly
FreeBSD 7-vintage), the configuration mostly "worked", and now at
$WORK I am responsible for making the configuration continue to work
in the future.  The customer in this case is completely unwilling to
modify their configuration.

I have a customer that has configured two different IPs on the same
subnet on two different interfaces.  The behaviour that they want is
that if the link on one of the two interfaces goes down, the route to
that subnet will migrate to the other IP on the other interface as a
quasi-failover behaviour.  Under FreeBSD 7, we had a daemon that
accomplished this by detecting the link loss and then using "route
change" to move the route to the up interface.  If the subnet in
question was 192.168.1.0/24, for example, we could run "route change
192.1.68.1.0/24 -ifp em1" to migrate the route.

Running on -head I run into two issues.  The first comes out of
r264986, which changes the behaviour of RTM_CHANGE.  The code path
changed significantly, but the part that impacts me is that now any
RTM_CHANGE command with the gateway set NULL gets EINVAL immediately
where previously it was allowed.  I've hacked around this problem
locally for testing purposes but I really don't understand the code
well enough at this point to see what a real fix would look like.

The second issue is quite complex.  The root cause is that the routing
code sets IFA_ROUTE on any ifaddr that has a local subnet route
associated with it.  If I don't migrate this flag to the new ifaddr,
very bizarre behaviour follows.  I've done a prototype that detects
when this migration is needed in rtrequest1_fib_change() and it works,
but IFA_ROUTE seems to otherwise be handled in individual L3 protocols
like in and in6, so I'm worried that this is a layering violation.  My
patch looks like this:
https://people.freebsd.org/~rstone/patches/route-change-subnet.diff


My first, and most important question, is whether a patch that would
allow a subnet route to be migrated to a different interface be
something that would be acceptable in FreeBSD?  If so, I need guidance
on what a proper fix for both issues would look like so that I can
implement fixes that I can upstream.

Thanks,
Ryan
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [PATCH] ifaddr leak when modifying a route

[Ryan Stone]

On Thu, Dec 7, 2017 at 4:59 PM, Ryan Stone <ryst...@gmail.com> wrote:
> https://reviews.freebsd.org/D13417

I still haven't received any feedback on this review.  If nobody
raises an objection by Thursday, I will commit it.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[PATCH] ifaddr leak when modifying a route

[Ryan Stone]

I've put this phab review up that patches an ifaddr refcount leak in
the routing code.  When a route is modified in a way that modifies
rt->rt_ifa, in most cases we don't release the reference on the old
one, which can cause it to leak.  I have a simple script here that I
wrote to demonstrate the issue:

https://people.freebsd.org/~rstone/route-change-leak

If I run it on a stock -head system, I see 100 ifaddrs leak every time it's run:

# sh route-change-leak
 Type InUse MemUse HighUse Requests  Size(s)
   ifaddr5317K   -  564  32,64,128,256,512,2048,4096
   ifaddr   15342K   -  664  32,64,128,256,512,2048,4096
# sh route-change-leak
 Type InUse MemUse HighUse Requests  Size(s)
   ifaddr   15342K   -  665  32,64,128,256,512,2048,4096
   ifaddr   25367K   -  765  32,64,128,256,512,2048,4096
# sh route-change-leak
 Type InUse MemUse HighUse Requests  Size(s)
   ifaddr   25367K   -  766  32,64,128,256,512,2048,4096
   ifaddr   35392K   -  866  32,64,128,256,512,2048,4096

With my fix, the leak is gone:

# sh route-change-leak
 Type InUse MemUse HighUse Requests  Size(s)
   ifaddr4615K   -   47  16,32,64,128,256,512,2048,4096
   ifaddr4615K   -  147  16,32,64,128,256,512,2048,4096
# sh route-change-leak
 Type InUse MemUse HighUse Requests  Size(s)
   ifaddr4615K   -  148  16,32,64,128,256,512,2048,4096
   ifaddr4615K   -  248  16,32,64,128,256,512,2048,4096

The review is here.  I didn't subscribe freebsd-net to the review to
try to reduce the noise on the mailing list, so if you would like to
review this change please subscribe yourself to the review.  Thanks.

https://reviews.freebsd.org/D13417
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: BPF packet pagesize limit

[Ryan Stone]

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, support for clusters > PAGE_SIZE should probably be retired
from the kernel given the significant havoc they cause.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Intel I210 (igb) sometimes consume all CPU on not-so-big traffic — need help!

[Ryan Stone]

Please try the following patch.  It should resolve your issue:

https://people.freebsd.org/~rstone/patches/e1000-9k.diff
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Should RO_RTFREE() also free the cached lle entry?

[Ryan Stone]

Ah, never mind.  When I started to investigate this problem I was
looking at an old tree.  I tried to verify that it was still a problem
on -head, but missed that r315956 fixed the problem in a different way
than I was expecting.  Sorry for the noise.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Should RO_RTFREE() also free the cached lle entry?

[Ryan Stone]

About a year back we brought back lle (the ARP/NDP entry) caching back
into the network stack.  As near as I can tell, the ethernet layer
will take a reference on the lle and place a pointer to it in the
ro_lle field in the struct route passed down from the upper layer.
The upper layer is expected to do something sensible with the lle.

This appears to have introduced bugs in code that doesn't perform
route caching.  For example, ip_forward() passes a struct route down
to ip_output(), but never checks if it needs to free an lle.
Similarly, if ip_output() is passed NULL for the route, it substitutes
a locally allocated one, and again does nothing with the lle.  I
believe that this means that these code paths now leak a reference on
the lle.

Both paths do call RO_RTFREE() on the struct route when they are done
with it.  I am wondering if the easiest path forward is to have that
macro also release the reference on the cached lle.  Otherwise fixing
this is going to require a very invasive change that fixes any caller
that ultimately might call into ether_output().
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ryan Stone]

Hans and I have proposed different approaches to the problem.  I was
taken off this issue at $WORK for a while, but coincidentally I just
picked it up again in the last week or so.  I'm working on evaluating
the performance characteristics of the two approaches and once I'm
satisfied with that I'll work with Hans to get a solution into the
tree.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ryan Stone]

I've just put up a review that fixes mlx4_en to no longer use clusters
larger than PAGE_SIZE in its receive path.  The patch is based off of the
older version of the driver which did the same, but keeps all of the
changes to the driver since then (including support for bus_dma).  The
review can be found here:

https://reviews.freebsd.org/D11560
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Question on SRIOV vf -> pf mapping

[Ryan Stone]

This isn't possible in general.  When PCI Passthrough is in use, the VF
driver will run in the context of the VM's kernel and there is no device_t
corresponding to the PF at all.  If you're looking to pass information from
the PF down to the VF, then you need to establish some kind of
device-mediated side-channel to pass the information from host to guest.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ryan Stone]

Having looking at the original email more closely, I see that you showed an
mlxen interface with a 9020 MTU.  Seeing allocation failures of 9k mbuf
clusters increase while you are far below the zone's limit means that
you're definitely running into the bug I'm describing, and this bug could
plausibly cause the iSCSI errors that you describe.

The issue is that the newer version of the driver tries to allocate a
single buffer to accommodate an MTU-sized packet.  Over time, however,
memory will become fragmented and eventually it can become impossible to
allocate a 9k physically contiguous buffer.  When this happens the driver
is unable to allocate buffers to receive packets and is forced to drop
them.  Presumably, if iSCSI suffers too many packet drops it will terminate
the connection.  The older version of the driver limited itself to
page-sized buffers, so it was immune to issues with memory fragmentation.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ryan Stone]

Is this setup using the mlx4_en driver?  If so, recent versions of that
driver has a regression when using MTUs greater than the page size (4096 on
i386/amd64).  The bug will cause the card to drop packets when the system
is under memory pressure, and in certain causes the card can get into a
state when it is no longer able to receive packets.  I am working on a fix;
I can post a patch when it's complete.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: vmx bug?

[Ryan Stone]

On Wed, May 17, 2017 at 7:32 PM, Andrew Vylegzhanin 
wrote:

>
> vmx0@pci0:4:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01
> hdr=0x00
>
> vendor = 'VMware'
>
> device = 'VMXNET3 Ethernet Controller'
>
> class  = network
>
> subclass   = ethernet
>
> vmx1@pci0:11:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01
> hdr=0x00
>
> vendor = 'VMware'
>
> device = 'VMXNET3 Ethernet Controller'
>
> class  = network
>
> subclass   = ethernet
>
> vmx2@pci0:19:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01
> hdr=0x00
>
> vendor = 'VMware'
>
> device = 'VMXNET3 Ethernet Controller'
>
> class  = network
>
> subclass   = ethernet
>
> vmx3@pci0:27:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01
> hdr=0x00
>
> vendor = 'VMware'
>
> device = 'VMXNET3 Ethernet Controller'
>
> class  = network
>
> subclass   = ethernet
>

 Everything appears to be enumerated in the proper order.  Do other OSes,
say Linux, somehow enumerate in a different order?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: vmx bug?

[Ryan Stone]

The bug that you refer to does not appear to be related to your issue.

What does "pciconf -l" print in your FreeBSD VM?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problems with FreeBSD (amd64 stable/11) router

[Ryan Stone]

Let me confirm I understand what's happening:

1) You want to use your router to vlan-tag traffic from your network, and
then send it out of a lagg over bce interfaces.  The bxe interfaces have
their MTU set to 1500 and the vlan interface to 1496
2) The TiVo is sending packets with a payload size of 1500 and the DF bit
set.

If this is the case, then the problem is simply that when the packets are
passed through the vlan interface, the payload of the packets exceeds the
MTU, but as the DF bit is set, the packets cannot be fragmented.  Your
choices are either to use a 1500 byte MTU on the vlan interface (assuming
that the network that you are routing to can accept 1518 byte packets), or
only advertise a 1496 byte MTU in your internal network.

On Mon, Dec 5, 2016 at 2:10 PM, Chris Ross <cross+free...@distal.com> wrote:

>
> > On Dec 5, 2016, at 11:59, Ryan Stone <ryst...@gmail.com> wrote:
> >
> > What's the MTU on the bce and vlan interfaces?  Does the bce interface
> show VLAN_MTU option set (in ifconfig)?
>
>   I had manually set these to try to work out the problem earlier in my
> experimentation, but am now back (unless I missed something) to the natural
> MTUs on all interfaces.  The vlan’s all show 1496, and the bee’s (and
> lagg0) show 1500.  The options on each of the bce’s show VLAN_MTU, and a
> few other VLAN_ options.
>
> - Chris
>
>
> > On Mon, Dec 5, 2016 at 10:00 AM, Chris Ross <cross+free...@distal.com>
> wrote:
> >
> >  Hello all.  I recently replaced my router with a FreeBSD/11 box
> (stable/11 r308579).  I am running a lagg device across two bce’s, and
> 802.1q vlan interfaces atop lagg0.  I’m using pf to NAT/filter out through
> a single outside IP address.
> >
> >  I’m having the following problem.  Some devices appear to be having
> trouble passing traffic.  Of course, I first assumed I was doing something
> wrong with my pf filters, but I believe now that’s not the problem.  One
> client machine (a TiVo Roamio) that produces a failure reliably, so I’ve
> been using it for testing, is showing that during a TCP session, which
> starts up fine, in the middle of a POST operation to an outside server,
> there are 1500 byte packets.  These packets have the DF bit in the IP
> header, and then never show up on the external interface (vlan0).  Smaller
> packets in the same TCP stream do.  But, I’m also not seeing the ICMP from
> the router back to the client telling it that it cannot send the packet.
> >
> >  I have tried all sorts of changes to my pf rules, including now
> allowing all ICMP unconditionally on all interfaces (pass out log quick
> inet proto icmp all).  I have packet traces during the failed communication
> across pflog0, vlan0 (external network) and vlan7 (internal network).  I’d
> be happy to answer any questions, or provide the traces off-list.
> >
> >  Does anyone have any idea what I’ve missed?  Thank you very much for
> your help.
> >
> > - Chris
> >
> > ___
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> >
>
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Problems with FreeBSD (amd64 stable/11) router

[Ryan Stone]

What's the MTU on the bce and vlan interfaces?  Does the bce interface show
VLAN_MTU option set (in ifconfig)?

On Mon, Dec 5, 2016 at 10:00 AM, Chris Ross 
wrote:

>
>  Hello all.  I recently replaced my router with a FreeBSD/11 box
> (stable/11 r308579).  I am running a lagg device across two bce’s, and
> 802.1q vlan interfaces atop lagg0.  I’m using pf to NAT/filter out through
> a single outside IP address.
>
>  I’m having the following problem.  Some devices appear to be having
> trouble passing traffic.  Of course, I first assumed I was doing something
> wrong with my pf filters, but I believe now that’s not the problem.  One
> client machine (a TiVo Roamio) that produces a failure reliably, so I’ve
> been using it for testing, is showing that during a TCP session, which
> starts up fine, in the middle of a POST operation to an outside server,
> there are 1500 byte packets.  These packets have the DF bit in the IP
> header, and then never show up on the external interface (vlan0).  Smaller
> packets in the same TCP stream do.  But, I’m also not seeing the ICMP from
> the router back to the client telling it that it cannot send the packet.
>
>  I have tried all sorts of changes to my pf rules, including now allowing
> all ICMP unconditionally on all interfaces (pass out log quick inet proto
> icmp all).  I have packet traces during the failed communication across
> pflog0, vlan0 (external network) and vlan7 (internal network).  I’d be
> happy to answer any questions, or provide the traces off-list.
>
>  Does anyone have any idea what I’ve missed?  Thank you very much for your
> help.
>
> - Chris
>
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mutex usage in if_bridge vs other drivers

[Ryan Stone]

On Fri, Dec 2, 2016 at 3:42 PM, Chris Torek  wrote:

> THE QUESTION:
>
>  - Who is wrong, the bxe driver or the bridge code?  I.e.,
>does the bridge driver need to release its lock here,
>and if so, is that actually safe to do? (We might need
>to restart the loop over all the members if we drop the
>lock.)
>
>  - Or if the bridge driver should retain its lock, can it
>use an sx lock here, to permit members to also use sx
>locks?
>

bxe is not the only driver that sleeps in its config path, so I would say
that if_bridge is de facto incorrect.  Dropping the lock is entirely the
wrong thing to do -- as you note, if we do, then the bridge members can
change out from under us.  The only path forward is to use an sx lock, but
unfortunately it's not quite as simple as just converting the lock to an sx
lock.  The problem is that BRIDGE_LOCK() is also called in the transmit and
receive paths, and those paths absolutely may not sleep for any reason.

I believe that the correct fix would be to introduce an sx lock to
if_bridge in additional to the current lock.  In code paths that call
ioctls() on bridge members, replace the use of BRIDGE_LOCK with the new sx
lock.  In code paths that modify the list of bridge members, hold both the
BRIDGE_LOCK and the new sx lock.  In the transmit and receive paths,
nothing should change.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D8685: Fix a false positive in a buf_ring assert

[rstone (Ryan Stone)]

This revision was automatically updated to reflect the committed changes.
rstone marked an inline comment as done.
Closed by commit rS309372: Fix a false positive in a buf_ring assert (authored 
by rstone).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D8685?vs=22633=22651#toc

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D8685?vs=22633=22651

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

AFFECTED FILES
  head/sys/sys/buf_ring.h

CHANGE DETAILS

diff --git a/head/sys/sys/buf_ring.h b/head/sys/sys/buf_ring.h
--- a/head/sys/sys/buf_ring.h
+++ b/head/sys/sys/buf_ring.h
@@ -67,11 +67,13 @@
uint32_t prod_head, prod_next, cons_tail;
 #ifdef DEBUG_BUFRING
int i;
-   for (i = br->br_cons_head; i != br->br_prod_head;
-i = ((i + 1) & br->br_cons_mask))
-   if(br->br_ring[i] == buf)
-   panic("buf=%p already enqueue at %d prod=%d cons=%d",
-   buf, i, br->br_prod_tail, br->br_cons_tail);
+   if (br->br_cons_head != br->br_prod_head) {
+   for (i = (br->br_cons_head + 1) & br->br_cons_mask; i != 
br->br_prod_head;
+   i = ((i + 1) & br->br_cons_mask))
+   if(br->br_ring[i] == buf)
+   panic("buf=%p already enqueue at %d prod=%d 
cons=%d",
+   buf, i, br->br_prod_tail, br->br_cons_tail);
+   }
 #endif 
critical_enter();
do {



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

To: rstone, hselasky
Cc: hselasky, freebsd-net-list, emaste
diff --git a/head/sys/sys/buf_ring.h b/head/sys/sys/buf_ring.h
--- a/head/sys/sys/buf_ring.h
+++ b/head/sys/sys/buf_ring.h
@@ -67,11 +67,13 @@
 	uint32_t prod_head, prod_next, cons_tail;
 #ifdef DEBUG_BUFRING
 	int i;
-	for (i = br->br_cons_head; i != br->br_prod_head;
-	 i = ((i + 1) & br->br_cons_mask))
-		if(br->br_ring[i] == buf)
-			panic("buf=%p already enqueue at %d prod=%d cons=%d",
-			buf, i, br->br_prod_tail, br->br_cons_tail);
+	if (br->br_cons_head != br->br_prod_head) {
+		for (i = (br->br_cons_head + 1) & br->br_cons_mask; i != br->br_prod_head;
+		i = ((i + 1) & br->br_cons_mask))
+			if(br->br_ring[i] == buf)
+panic("buf=%p already enqueue at %d prod=%d cons=%d",
+buf, i, br->br_prod_tail, br->br_cons_tail);
+	}
 #endif	
 	critical_enter();
 	do {

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D8685: Fix a false positive in a buf_ring assert

[rstone (Ryan Stone)]

rstone marked an inline comment as done.
rstone added inline comments.

INLINE COMMENTS

> hselasky wrote in buf_ring.h:71
> should "br->br_cons_head + 1" be masked by br->br_cons_mask ??

Absolutely correct.  Nice catch, thank you

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

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

To: rstone
Cc: hselasky, freebsd-net-list, emaste
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D8685: Fix a false positive in a buf_ring assert

[rstone (Ryan Stone)]

rstone updated this revision to Diff 22633.
rstone added a comment.


  Ensure we don't walk off the end of the ring

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D8685?vs=22631=22633

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

AFFECTED FILES
  sys/sys/buf_ring.h

CHANGE DETAILS

diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h
--- a/sys/sys/buf_ring.h
+++ b/sys/sys/buf_ring.h
@@ -67,11 +67,13 @@
uint32_t prod_head, prod_next, cons_tail;
 #ifdef DEBUG_BUFRING
int i;
-   for (i = br->br_cons_head; i != br->br_prod_head;
-i = ((i + 1) & br->br_cons_mask))
-   if(br->br_ring[i] == buf)
-   panic("buf=%p already enqueue at %d prod=%d cons=%d",
-   buf, i, br->br_prod_tail, br->br_cons_tail);
+   if (br->br_cons_head != br->br_prod_head) {
+   for (i = (br->br_cons_head + 1) & br->br_cons_mask; i != 
br->br_prod_head;
+   i = ((i + 1) & br->br_cons_mask))
+   if(br->br_ring[i] == buf)
+   panic("buf=%p already enqueue at %d prod=%d 
cons=%d",
+   buf, i, br->br_prod_tail, br->br_cons_tail);
+   }
 #endif 
critical_enter();
do {



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

To: rstone
Cc: hselasky, freebsd-net-list, emaste
diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h
--- a/sys/sys/buf_ring.h
+++ b/sys/sys/buf_ring.h
@@ -67,11 +67,13 @@
 	uint32_t prod_head, prod_next, cons_tail;
 #ifdef DEBUG_BUFRING
 	int i;
-	for (i = br->br_cons_head; i != br->br_prod_head;
-	 i = ((i + 1) & br->br_cons_mask))
-		if(br->br_ring[i] == buf)
-			panic("buf=%p already enqueue at %d prod=%d cons=%d",
-			buf, i, br->br_prod_tail, br->br_cons_tail);
+	if (br->br_cons_head != br->br_prod_head) {
+		for (i = (br->br_cons_head + 1) & br->br_cons_mask; i != br->br_prod_head;
+		i = ((i + 1) & br->br_cons_mask))
+			if(br->br_ring[i] == buf)
+panic("buf=%p already enqueue at %d prod=%d cons=%d",
+buf, i, br->br_prod_tail, br->br_cons_tail);
+	}
 #endif	
 	critical_enter();
 	do {

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D8685: Fix a false positive in a buf_ring assert

[rstone (Ryan Stone)]

rstone added a subscriber: freebsd-net-list.

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

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

To: rstone
Cc: freebsd-net-list, emaste
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: lagg Interfaces - don't do Gratuitous ARP?

[Ryan Stone]

On Thu, Sep 22, 2016 at 4:04 AM, Steven Hartland 
wrote:

> The disappointing thing about this is we had a solution, all be it one not
> everyone liked, nearly a year ago now and yet here we are still stuck with
> a broken lagg implementation in the tree.
>

I would point out this 4-year-old thread in which a former co-worker
pointed the same issue with GARPs not being issued and proposed a fix that
was rejected (rightly) for being too much of a layer violation.  It's
disappointing to me to see that somebody has fixed the issue in exactly the
way proposed in this thread, only to have the method that was correct 4
years ago rejected today.

https://lists.freebsd.org/pipermail/freebsd-net/2012-February/031328.html
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: lagg Interfaces - don't do Gratuitous ARP?

[Ryan Stone]

On Wed, Sep 21, 2016 at 7:57 PM, Gleb Smirnoff  wrote:

> IMHO, the original patch was absolutely evil hack touching multiple
> layers, for the sake of a very special problem.
>
> I think, that in order to kick forwarding table on switches, lagg
> should:
>
> - allocate an mbuf itself
> - set its source hardware address to its own
> - set destination hardware to broadcast
> - put some payload in there, to make packet of valid size. Why should it be
>   gratuitous ARP? A machine can be running IPv6 only, or may even use
> whatever
>   higher level protocol, e.g. PPPoE. We shouldn't involve IP into this
> Layer 2
>   problem at all.
> - Finally, send the prepared mbuf down the lagg member(s).
>
> And please don't hack half of the network stack to achieve that :)
>

The original report in this thread is about a system where it takes almost
15 minutes for the network to start working again after a failover.  That
does not sound to me like a switch problem.  That sounds to me like the ARP
cache on the remote system.  To fix such a case we have to touch L3.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How can I send packets to 255.255.255.255 from the command line?

[Ryan Stone]

On Thu, Aug 18, 2016 at 4:48 PM, Paul A. Procacci 
wrote:

> You should be able to ping the local subnet.
> Alternatively you can use net/arping.
>
> ~Paul
>

I'm specifically looking to test the handling of 255.255.255.255, so a
local broadcast address is out.  Unfortunately, arping doesn't seem to do
the right thing on FreeBSD.  It manages to get the kernel to try arp'ing
for 255.255.255.255.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

How can I send packets to 255.255.255.255 from the command line?

[Ryan Stone]

I want to test a change to broadcast packet handling and I want to confirm
that 255.255.255.255 is still handled correctly. Are there any command-line
tools in FreeBSD that can send to the broadcast address?  ping
255.255.255.255 does not work correctly, unfortunately.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Unstable local network throughput

[Ryan Stone]

On Thu, Aug 4, 2016 at 11:33 AM, Ben RUBSON  wrote:

> But even without RSS, I should be able to go up to 2x40Gbps, don't you
> think so ?
> Nobody already did this ?
>

Try this patch, which should improve performance when multiple TCP streams
are running in parallel over an mlx4_en port:

https://people.freebsd.org/~rstone/patches/mlxen_counters.diff
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Is netmap jumbo frames broken in STABLE?

[Ryan Stone]

The use of mbuf clusters larger than a single page really doesn't work.
The problem is that over time physical memory becomes fragmented and
eventually 9K of contiguous memory can't be allocated anymore.  This is why
many drivers now limit themselves to page-sized clusters.

On Mon, Jun 6, 2016 at 10:03 AM, Luigi Rizzo  wrote:

> On Mon, Jun 6, 2016 at 3:22 PM, Andrew Vylegzhanin 
> wrote:
>
> > Hello all,
> >
> >
> > I have an application that uses netmap for capture jumbo frames. The
> frames
> > are fixed size and have fixed rate (for example size 5166, rate 5
> pps).
> > The frames are pure Ethernet, without IP header.
> >
> >
> > Everything works fine in 10.0-RELEASE, 10.1-RELEASE.
> >
> >
> > Starting from 10.3 and actual 10-STABLE I've got wrong data from netmap
> > ring. It's looks like packet data broke and packet split on two parts
> 4092
> > and 1070 bytes,  where original size was 5166.
> >
> > A code ring precessing is based on macros from netmap_user.h :
> >
> >
> > n = nm_ring_space(ring);
> >
> > for (rx = 0; rx < limit; rx++) {
> >
> > struct netmap_slot *slot = >slot[cur];
> >
> > char *p = NETMAP_BUF(ring, slot->buf_idx);
> >
> > process_payload(p, slot->len, datapx);
> >
> > cur = nm_ring_next(ring, cur);
> >
> > }
> >
> > ring->head = ring->cur = cur;
> >
> >
> > Here is netmap sysctl's:
> >
> > dev.netmap.buf_num=81920
> >
> > dev.netmap.ring_size=73728
> >
> > dev.netmap.buf_size=5248
> >
> >
> > Hardware is Dell R720 (2x E5-2643 v2) with four Intel Ethernet 10G 2P
> X520
> > Adapter. I use only one hardware queue per interface.
> >
> >
> > BTW, may be a new version of Intel ixgbe driver (3.1.13-k) is a reason?
> >
> >
> ​Hi,
> yes I suspect the problem may be in the new ixgbe driver,
> probably it programs the hardware to limit buffer sizes to 4k
> even when large MTUs are in use,
> so the receiver will split
> the incoming frame in two buffers, while netmap is expecting
> only one.
> I suggest to have a look at the ioctl handler (in the driver)
> that handles the MTU setting and compare with the code
> in the previous driver.
>
> cheers
> luigi
>
>
> > Does it make sense to try with 11-CURRENT?
> >
> >
> > Thank you in advance.
> >
> >
> > --
> >
> > Andrew
> > ___
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> >
>
>
>
> --
> -+---
>  Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
>  http://www.iet.unipi.it/~luigi/. Universita` di Pisa
>  TEL  +39-050-2217533   . via Diotisalvi 2
>  Mobile   +39-338-6809875   . 56122 PISA (Italy)
> -+---
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: VLANs are broken in HEAD

[Ryan Stone]

r299512 introduced breakage into dhclient, which was fixed in r300174.
That may be the source of the issue?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Regression? VLAN packet drop after upgrading from r281235

[Ryan Stone]

From a quick look at the vlan code, I can identify a few cases that might
cause that counter to increment:

1) Error from the underlying ixgbe device.  Does "netstat -dI ix0" show
that the driver has been dropping packets?

2) Link down events on the underlying NIC.  I believe that link flaps will
be logged to /var/log/messages and dmesg; do you see anything there that
might correspond to the time of the packet drops?

3) If VLAN_HWTAGGING is disabled through ifconfig on the port, then in
theory a low memory event could cause the packet to be dropped.  Does
"netstat -m" show that "requests for mbufs denied" increasing?


On Wed, Apr 27, 2016 at 2:41 PM, Zé Claudio Pastore 
wrote:

> Hello,
>
> On a BGP border router I help manage, we run FreeBSD 10.1-STABLE,
> version r281235 and it works fine for several years now.
>
> We have around 4Gbit/s and 1.8Mpps routed on peak while per port interface
> we peak at 300Kpps.
>
> Our quality metrics are measured with:
>
> ping -s 1472 -i 0.1 
>
> As well as iperf bidirecional.
>
> This metric is similar to what Speedy Test and SIMET tests are done and our
> customers reference.
>
> Systems working w/o problem:
> - 10.1-STABLE / r281235
>
> Systems tested with drops:
> - 10.2-STABLE / r292035M
> - 10.3-STABLE / r298705
> - 11.0-CURRENT / r295683 (downloaded snapshot from ftp.freebsd.org)
> - 11.0-CURRENT Melifaro Routing Branch / r297731M
>
> While testing, when errors happen I can see output errs on the vlan port on
> the output from "netstat -w1 -I vlan6"
>
>input  vlan6   output
>packets  errs idrops  bytespackets  errs  bytes colls
>  1 0 0 66  30557 2   33310968 0
>  1 0 0105  31458 3   33912219 0
>  2 0 0   2954  32001 8   34983986 0
>  1 0 0   1512  33150 6   35942558 0
>  1 0 0   1512  33654 4   37311862 0
>  1 0 0   1512  34825 3   38213793 0
>  3 0 0   1683  35376 4   39488912 0
>  5 0 0   7280  32423 3   35551869 0
>
> Problems may happen under high load (~200Kpps) or low load (~30Kpps) on a
> vlan port. The observed frame loss never happens on untagged ports, only
> vlan related. The observed loss happens with packets sized 900 bytes and
> above but noticeably loss rate is higher with packets close to 1400 (1472
> is my reference size).
>
> Loss rate on all listed systems different from r281235 is 9-19% with
> ping(1) and iperf, while it's 0% on r281235.
>
> First I believed it to be a Intel driver error on systems newer than 10.1.
> My reference card are dual port 82599EB 10-Gigabit SFI/SFP+ Network
> Connection (2x2 on x8 PCIe bus, total 4x10G). But yesterday I replaced
> Intel by Chelsio T5 and the problem is still exactly the same, so it's not
> related to card vendor.
>
> I always test the very same hardware, I have two SSD drives in this router,
> one for the 10.1 which just runs fine and the other disk to test the
> various versions of FreeBSD.
>
> Only minor loader and sysctl confs are tweaked:
>
> kern.hz=2000
> net.inet.ip.redirect=1# do not send IP redirects
> net.inet.ip.accept_sourceroute=0  # drop source routed packets since
> they ca
> net.inet.ip.sourceroute=0 # if source routed packets are
> accepted th
> net.inet.tcp.drop_synfin=1# SYN/FIN packets get dropped on
> initial c
> net.inet.udp.blackhole=1  # drop udp packets destined for
> closed soc
> net.inet.tcp.blackhole=2  # drop tcp packets destined for
> closed por
> security.bsd.see_other_uids=0
>
> Can anyone suggest what might be a fix/tuning for this behavior? Was there
> any relevant change on vlan code from particular revisions close to the one
> I run on 10.1 and later which would lead to such a big difference?
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Persist ifconfig aliases after disconnect

[Ryan Stone]

When you say the "connection drops", do you mean that the NIC loses link
and then has it comes back?  Are you using DHCP to get the main address?
It sounds like perhaps dhclient is running and clearing the addresses it
doesn't know about.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Outgoing packets being sent via wrong interface

[Ryan Stone]

An easier way to block ICMP redirects would be to set the sysctl:

sysctl net.inet.icmp.drop_redirect=1
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Intel XL710 broken link down detection?

[Ryan Stone]

On Wed, Nov 11, 2015 at 11:18 AM, Steven Hartland 
wrote:

> Comparing this to the Linux driver which does detect the link down I've
> discovered it actually polls the link status by default in its watchdog.
>
> Disabling this with "ethtool --set-priv-flags eth1 LinkPolling off" and
> the Linux driver also fails to detect link down.
>
> So this seems like a firmware or even hardware bug where it should be
> reporting down events and the Linux driver has been updated to workaround
> the problem?


No, apparently the Linux devs just didn't read the datasheet closely enough
(and presumably the FreeBSD driver copied the mistake).  There is a mask of
interrupt causes that works backwards from how one would expect; you mask
out events that you *don't* want rather than events that you do want.  Both
the Linux and FreeBSD drivers pass a mask of events that they want
interrupts for (the only reason why it appears to work on link up is that
the the AN Completed event fires when link is up, as far as I can tell).
Try the following patch:

https://people.freebsd.org/~rstone/patches/ixl_link_int.diff
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

route command will perform DNS lookup of invalid interface name

[Ryan Stone]

At $WORK, we have observed that if you attempt to add a route with the
-iface flag, but you specify an incorrect interface name, the route command
will perform a DNS lookup of the interface name.  It appears that if the
DNS lookup succeeds that it will treat the parameter to -iface as if it
were a gateway for the route and not an interface.

This appears to be a simple bug.  This patch resolves the issue for me, but
I'm a bit worried that the fallback to a DNS lookup might actually be
desired behaviour in some case.  Does anybody have any ideas?

diff --git a/sbin/route/route.c b/sbin/route/route.c
index 1bce41e..a447a45 100644
--- a/sbin/route/route.c
+++ b/sbin/route/route.c
@@ -1222,6 +1222,9 @@ getaddr(int idx, char *str, struct hostent **hpp, int
nrflags)
freeifaddrs(ifap);
if (sdl != NULL)
return(1);
+   else
+   errx(EX_DATAERR,
+   "inferface '%s' does not exist", str);
}
break;
case RTAX_IFP:
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [RFC] ifconfig description

[Ryan Stone]

On Jul 28, 2015 11:07 AM, Sergey Kandaurov pluk...@freebsd.org wrote:

 On 28 July 2015 at 20:55, Alexander V. Chernikov melif...@freebsd.org
wrote:
  28.07.2015, 15:32, Arseny Nasokin eir...@gmail.com:
 
  Separate ifconfig_IF_description will be simpler to use.
 
  I was also insisting on this..
  +pluknet@
  Sergey, maybe we could reconsider this stuff and add separate
_description
  field?

 No, thanks.

 That means that we should also build up ifconfig_IF_group,
 ifconfig_IF_name and suchalikes for parity.
 I wouldn't object strongly though if someone will come up with a patch.

 --
 wbr,
 pluknet
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Doesn't ifconfig_*_name already exist?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Reg Intel Fortville IXL driver on 11-CURRENT

[Ryan Stone]

On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan 
lakshm...@msystechnologies.com wrote:

 [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c
 ixl_txrx.c.mod
 *** ixl_txrx.c Fri Jun 12 06:56:51 2015
 --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015
 *** ixl_mq_start(struct ifnet *ifp, struct m
 *** 96,112 
 --- 96,115 
   } else
   #endif
   i = m-m_pkthdr.flowid % vsi-num_queues;
   } else
   i = curcpu % vsi-num_queues;
 +
 + #if 0
   /*
   ** This may not be perfect, but until something
   ** better comes along it will keep from scheduling
   ** on stalled queues.
   */
   if (((1  i)  vsi-active_queues) == 0)
   i = ffsl(vsi-active_queues);
 + #endif

   que = vsi-queues[i];
   txr = que-txr;

   err = drbr_enqueue(ifp, txr-br, m);
 [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$


My understanding is that this code is intended to be triggered as a last
resort.  If that code is firing regularly then the driver is not correctly
tracking which queues are alive in the active_queues bitmask.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Updated] D1986: Teach lagg(4) to change MTU

[rstone (Ryan Stone)]

rstone added a comment.

RLOCK only gets a read lock.  You want WLOCK to get a write lock to ensure 
serialization.

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

To: rpokala-panasas.com, rstone
Cc: ae, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Commented On] D1986: Teach lagg(4) to change MTU

[rstone (Ryan Stone)]

rstone added inline comments.

INLINE COMMENTS
  sys/net/if_lagg.c:1772 style(9) says to not include unnecessary braces (which 
I personally disagree with, but what can you do?)
  sys/net/if_lagg.c:1773 style(9): put brackets around the return value:
  
  return (0);
  sys/net/if_lagg.c:1811 I find the flow control here a bit confusing (my first 
read through, I thought that err2 could be used unitinialized).  Given that you 
have a continue in the if block, I would find it clearer to not have an else 
here

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

To: rpokala-panasas.com, rstone
Cc: ae, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Changed Subscribers] D1986: Teach lagg(4) to change MTU

[rstone (Ryan Stone)]

rstone added a subscriber: freebsd-net.

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

To: rpokala-panasas.com, rstone
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1882: Add macros to make code compile in kernel

[rstone (Ryan Stone)]

rstone closed this revision.
rstone updated this revision to Diff 4041.
rstone added a comment.

Closed by commit rS279438 (authored by @rstone).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1882?vs=3825id=4041#toc

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

AFFECTED FILES
  head/lib/libnv/dnv.h
  head/lib/libnv/dnvlist.c
  head/lib/libnv/nv.h
  head/lib/libnv/nv_impl.h
  head/lib/libnv/nvlist.c
  head/lib/libnv/nvlist_impl.h
  head/lib/libnv/nvpair.c
  head/lib/libnv/nvpair_impl.h

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1883: Move libnv into the kernel and hook it into the kernel build

[rstone (Ryan Stone)]

rstone closed this revision.
rstone updated this revision to Diff 4043.
rstone added a comment.

Closed by commit rS279439 (authored by @rstone).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1883?vs=3826id=4043#toc

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

AFFECTED FILES
  head/lib/libnv/Makefile
  head/lib/libnv/dnv.h
  head/lib/libnv/dnvlist.c
  head/lib/libnv/nv.h
  head/lib/libnv/nv_impl.h
  head/lib/libnv/nvlist.c
  head/lib/libnv/nvlist_impl.h
  head/lib/libnv/nvpair.c
  head/lib/libnv/nvpair_impl.h
  head/sys/conf/files
  head/sys/kern/subr_dnvlist.c
  head/sys/kern/subr_nvlist.c
  head/sys/kern/subr_nvpair.c
  head/sys/sys/dnv.h
  head/sys/sys/nv.h
  head/sys/sys/nv_impl.h
  head/sys/sys/nvlist_impl.h
  head/sys/sys/nvpair_impl.h

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1870: Add tests for nvlist_clone

[rstone (Ryan Stone)]

rstone closed this revision.
rstone updated this revision to Diff 4038.
rstone added a comment.

Closed by commit rS279425 (authored by @rstone).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1870?vs=3862id=4038#toc

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

AFFECTED FILES
  head/lib/libnv/tests/nv_tests.cc

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1880: Prevent creation of an invalid nvlist

[rstone (Ryan Stone)]

rstone closed this revision.
rstone updated this revision to Diff 4040.
rstone added a comment.

Closed by commit rS279436 (authored by @rstone).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1880?vs=3823id=4040#toc

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

AFFECTED FILES
  head/lib/libnv/nvpair.c
  head/lib/libnv/tests/nv_tests.cc

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1879: Don't allocate memory for operations that do not insert

[rstone (Ryan Stone)]

rstone closed this revision.
rstone updated this revision to Diff 4039.
rstone added a comment.

Closed by commit rS279435 (authored by @rstone).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1879?vs=3822id=4039#toc

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

AFFECTED FILES
  head/lib/libnv/dnvlist.c
  head/lib/libnv/nv_impl.h
  head/lib/libnv/nvlist.c

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

HEADS UP: PCI SR-IOV infrastructure has been committed to head

[Ryan Stone]

I've just finished committing support for PCI Single Root I/O
Virtualization in the pci subsystem to head.  This should be a no-op
for everyone right now, but there were some minor refactorings in the
pci code that could have a lingering bug.  I did make sure to test
that it boots on a variety of systems (but only i386/amd64, as that's
all that I have access to).

What's been committed to head is only the pci subsystem side of
things, along with the userland tools to configure SR-IOV (along with,
I'm happy to say, a full set of man pages).  What's not in head yet
are any drivers making use of the infrastructure.  Full support for
ixl(4) is complete and I've sent the patch to jfv@; I hope to see the
driver support committed soon.  I don't have any word on timelines for
getting support in other drivers.  Unfortunately adding SR-IOV support
to a driver is not trivial as the standard leaves a lot of the details
up to particular implementations (in the same way the the PCIe
standard does not define how to send a packet from a NIC; instead
defining how the PCIe device will expose its registers and whatnot,
and its up to the PCIe device and driver to understand how to poke at
the registers to send a packet).  I have heard anecdotally that a
number of driver maintainers have been very interested in this work so
I hope that to see more drivers supported SR-IOV in the near future.
I encourage all driver maintainers to read over the new manpages and
contact me if they have any questions about the new infrastructure.

Anybody interested in using SR-IOV should try to attend BSDCan 2015,
as I will be giving a talk on the subject.  I intend to focus more on
the system administration side of configuring and using SR-IOV rather
than the details of implementing an SR-IOV driver.

If anybody did an svn up half-way through my muddled series of
commits, sorry about the temporary breakage.  My
buildworld/buildkernel on r279466 just completed successfully so
please make sure that you have at least that revision.  If you still
have problems, please let me know.

I do want to thank John Baldwin for advice about the PCI Subsystem and
newbus and Jack Vogel for his help with the Fortville NIC, including
getting me early access to the VF driver for testing purposes.  Thanks
to everybody who reviewed the changes.  Specially thanks to Mark
Johnston and Sean Mahood, who literally spent hours with me in a
meeting room reviewing the entire patch series last summer
(thankfully, those hours at least weren't consecutive).

Above all, thanks to Sandvine Inc. for sponsoring this work.  This is
definitely the biggest contribution we've ever made to FreeBSD and I
hope to see this kind of thing continue.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: netmap support for the Intel 40G card in head

[Ryan Stone]

This is great!  Thanks to both you and Intel.  I'm planning on getting
SR-IOV support into head this week, which would allow you to create
ixlv instances (on the same hardware).  Any chance that you'd have the
time to look into supporting SR-IOV for that driver too?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1881: Allow Illumos code to co-exist with nv(9)

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, will
Cc: will, emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: FreeBSD 10.1: Intel dual port 10GbE card (82599EB) second port not present?

[Ryan Stone]

I think that you might be a bit confused about the behaviour.  An ix
port will only be missing if

a) You have a non-Intel SFP+ installed
b) hw.ix.unsupported_sfp=1 is not set in loader.conf

ix ports that have no SFP+ installed do show up in ifconfig
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

[rstone (Ryan Stone)]

rstone added a comment.

Err, that was supposed to be installed it into a couple of *VMs*

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

To: rstone, jfvogel
Cc: will, emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

[rstone (Ryan Stone)]

rstone added a comment.

Ok, I did a full buildworld/buildkernel (with device zfs in my kernel config) 
and installed it into a couple of zfs.  I tested creating a zpool out of a mfs 
disk, creating filesystems, setting some properties, doing a git clone into a 
file system, and then doing a zfs send of the result from one vm to the 
problem.  No problems cropped up.

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

To: rstone, jfvogel
Cc: will, emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1877: Implement asprintf in libkern

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1869: Tests of basic nvlist add functions

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1874: Add tests for nvlist_free* functions

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1876: Add tests for dnvlist_take_*

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1875: Add tests for dnv_get_*

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1872: Add test cases for nvlist_move_*

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1873: Add tests for nvlist_take_*

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1871: Add tests for nvlist_pack/unpack

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1878: Add function to force an nvlist into the error state

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1868: Make libnv headers includable from C++

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Updated, 120 lines] D1870: Add tests for nvlist_clone

[rstone (Ryan Stone)]

rstone updated this revision to Diff 3862.
rstone added a comment.
This revision now requires review to proceed.

Fix the test case to actually test the clone

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D1870?vs=3813id=3862

BRANCH
  review_D1870

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

AFFECTED FILES
  lib/libnv/tests/nv_tests.cc

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1648: Add stubs for deprecated VC messages

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

[rstone (Ryan Stone)]

rstone added a comment.

The primary testing that I did was to ensure that a kernel with device zfs 
would still link.  However, I suppose that doesn't exclude the possibility of 
their being an zfs source file that is built wrong and doesn't include this 
header.  Is there a zfs test suite that I could run?

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

To: rstone, jfvogel
Cc: will, emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Request, 7 lines] D1868: Make libnv headers includable from C++

[rstone (Ryan Stone)]

rstone created this revision.
rstone added a reviewer: jfvogel.
rstone added subscribers: pjd, freebsd-net.

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

AFFECTED FILES
  lib/libnv/dnv.h
  lib/libnv/nv.h

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Request, 309 lines] D1869: Tests of basic nvlist add functions

[rstone (Ryan Stone)]

rstone created this revision.
rstone added a reviewer: jfvogel.
rstone added subscribers: pjd, freebsd-net.

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

AFFECTED FILES
  lib/libnv/Makefile
  lib/libnv/tests/Makefile
  lib/libnv/tests/nv_tests.cc

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Request, 185 lines] D1871: Add tests for nvlist_pack/unpack

[rstone (Ryan Stone)]

rstone created this revision.
rstone added a reviewer: jfvogel.
rstone added subscribers: pjd, freebsd-net.

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

AFFECTED FILES
  lib/libnv/tests/nv_tests.cc

To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1660: Add support for mac-addr parameter

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1661: Add some security-related config parameters

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[Differential] [Closed] D1644: Add infrastructure for handling the VC msg channel from VFs

[rstone (Ryan Stone)]

rstone closed this revision.

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

To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org