Re: svn commit: r304436 - in head: . sys/netinet

On Sun, Aug 28, 2016 at 10:20:08AM -0700, Adrian Chadd wrote: > Hi, > > There are some no brainers here so far(tm): > > working from the bottom up: > > * yeah, the ixgbe locking is a bit silly. Kip's work with iflib and > converting ixgbe to use that instead of its own locking for managing >

Re: svn commit: r304436 - in head: . sys/netinet

On Sun, Aug 28, 2016 at 10:20:08AM -0700, Adrian Chadd wrote: > Then the rest of the big entries are just a combination of rtentry > locking, tcp timer locking, zfs locking and madvise locking. There's > some sowakeup locking there as well, from the socket producer/consumer > locking. On some

Re: svn commit: r304436 - in head: . sys/netinet

On 29 August 2016 at 15:00, Gleb Smirnoff wrote: > On Sat, Aug 20, 2016 at 12:36:58PM -0400, Ryan Stone wrote: > R> - The if_addr_lock would appear to be an excellent candidate to be > R> converted into an rmlock, but unfortunately we made the mistake of exposing > R> the

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 11:27:25AM -0400, Ryan Stone wrote: R> > where the link layer does not have the concept of broadcast being distinct R> > from other kinds of network traffic. PPP and ATM are the most obvious R> > examples. R> R> We don't support ATM, but PPP is a good example. We support

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 12:36:58PM -0400, Ryan Stone wrote: R> - The if_addr_lock would appear to be an excellent candidate to be R> converted into an rmlock, but unfortunately we made the mistake of exposing R> the lock through the ifnet KPI. Fixing that would require rototilling R> every single

Re: svn commit: r304436 - in head: . sys/netinet

On Sun, Aug 28, 2016 at 10:20:08AM -0700, Adrian Chadd wrote: > * the rtalloc1_fib thing - that's odd, because it shouldn't be > contending there unless there's some temporary redirect that's been > learnt. What's the routing table look like on your machine? I Remember > investigating the rtentry

Re: svn commit: r304436 - in head: . sys/netinet

Hi, There are some no brainers here so far(tm): working from the bottom up: * yeah, the ixgbe locking is a bit silly. Kip's work with iflib and converting ixgbe to use that instead of its own locking for managing things should remove the bottom two locks * the rtalloc1_fib thing - that's odd,

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 27, 2016 at 07:05:01PM -0700, Adrian Chadd wrote: > On 26 August 2016 at 17:46, Slawa Olhovchenkov wrote: > > On Fri, Aug 26, 2016 at 04:55:34PM -0700, Adrian Chadd wrote: > > > >> Hi, > >> > >> I use the kernel lock profiling debugging, > > > > I am already have

Re: svn commit: r304436 - in head: . sys/netinet

On 26 August 2016 at 17:46, Slawa Olhovchenkov wrote: > On Fri, Aug 26, 2016 at 04:55:34PM -0700, Adrian Chadd wrote: > >> Hi, >> >> I use the kernel lock profiling debugging, > > I am already have 100% utilise all CPU cores, I think this is drop > performance? > >> but you can

Re: svn commit: r304436 - in head: . sys/netinet

On Fri, Aug 26, 2016 at 04:55:34PM -0700, Adrian Chadd wrote: > Hi, > > I use the kernel lock profiling debugging, I am already have 100% utilise all CPU cores, I think this is drop performance? > but you can use dtrace to > get an idea: > > dtrace -n 'lockstat:::adaptive-block { @[stack()] =

Re: svn commit: r304436 - in head: . sys/netinet

Hi, I use the kernel lock profiling debugging, but you can use dtrace to get an idea: dtrace -n 'lockstat:::adaptive-block { @[stack()] = sum(arg1); }' (https://wiki.freebsd.org/DTrace/One-Liners) -adrian ___ svn-src-head@freebsd.org mailing list

Re: svn commit: r304436 - in head: . sys/netinet

On Fri, Aug 26, 2016 at 02:42:27PM -0700, Adrian Chadd wrote: > On 26 August 2016 at 14:36, Slawa Olhovchenkov wrote: > > On Fri, Aug 26, 2016 at 02:32:00PM -0700, Adrian Chadd wrote: > > > >> Hi, > >> > >> It's pcb lock contention. > > > > Not sure: only 5% of all time. > > And

Re: svn commit: r304436 - in head: . sys/netinet

On 26 August 2016 at 14:36, Slawa Olhovchenkov wrote: > On Fri, Aug 26, 2016 at 02:32:00PM -0700, Adrian Chadd wrote: > >> Hi, >> >> It's pcb lock contention. > > Not sure: only 5% of all time. > And same 5% for tcbhashsize = 65K and 256K. > Or you talk about some more thin

Re: svn commit: r304436 - in head: . sys/netinet

On Fri, Aug 26, 2016 at 02:32:00PM -0700, Adrian Chadd wrote: > Hi, > > It's pcb lock contention. Not sure: only 5% of all time. And same 5% for tcbhashsize = 65K and 256K. Or you talk about some more thin effect? > > On 26 August 2016 at 08:13, Slawa Olhovchenkov wrote: > >

Re: svn commit: r304436 - in head: . sys/netinet

Hi, It's pcb lock contention. -adrian On 26 August 2016 at 08:13, Slawa Olhovchenkov wrote: > On Fri, Aug 26, 2016 at 04:01:14PM +0100, Bruce Simpson wrote: > >> Slawa, >> >> I'm afraid this may be a bit of a non-sequitur. Sorry.. I seem to be >> missing something. As I

Re: svn commit: r304436 - in head: . sys/netinet

On Fri, Aug 26, 2016 at 04:01:14PM +0100, Bruce Simpson wrote: > Slawa, > > I'm afraid this may be a bit of a non-sequitur. Sorry.. I seem to be > missing something. As I understand it this thread is about Ryan's change > to netinet for broadcast. > > On 26/08/16 15:49, Slawa Olhovchenkov

Re: svn commit: r304436 - in head: . sys/netinet

Slawa, I'm afraid this may be a bit of a non-sequitur. Sorry.. I seem to be missing something. As I understand it this thread is about Ryan's change to netinet for broadcast. On 26/08/16 15:49, Slawa Olhovchenkov wrote: On Sun, Aug 21, 2016 at 03:04:00AM +0300, Slawa Olhovchenkov wrote: On

Re: svn commit: r304436 - in head: . sys/netinet

On Sun, Aug 21, 2016 at 03:04:00AM +0300, Slawa Olhovchenkov wrote: > On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: > > > On 20/08/16 23:05, Slawa Olhovchenkov wrote: > > > I am think this substitution is very bad idea (by design). > > > Also, on transmit side this is must be

Re: svn commit: r304436 - in head: . sys/netinet

On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: > On 20/08/16 23:05, Slawa Olhovchenkov wrote: > > I am think this substitution is very bad idea (by design). > > Also, on transmit side this is must be irrelevant on received L2 > > header (and this in many cases this is will be L2

Re: svn commit: r304436 - in head: . sys/netinet

On 21/08/16 00:47, Adrian Chadd wrote: [snip] Just for everyone else on the list, would you mind distilling the original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how they're supposed to be used? (With my best Liam Neeson 'Dad' voice from Fallout 3) They stay as-is, but IP is

Re: svn commit: r304436 - in head: . sys/netinet

[snip] Just for everyone else on the list, would you mind distilling the original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how they're supposed to be used? thanks, -adrian ___ svn-src-head@freebsd.org mailing list

Re: svn commit: r304436 - in head: . sys/netinet

On 21/08/16 00:25, Bruce Simpson wrote: On 20/08/16 23:05, Slawa Olhovchenkov wrote: In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of

Re: svn commit: r304436 - in head: . sys/netinet

On 21/08/16 00:25, Bruce Simpson wrote: [Use a predicted branch in favour of Ethernet to optimize common case comments snipped] ...we ensure that M_BCAST is cleared at all times before possible re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols decide themselves if

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 23:05, Slawa Olhovchenkov wrote: I am think this substitution is very bad idea (by design). Also, on transmit side this is must be irrelevant on received L2 header (and this in many cases this is will be L2 unicast packet). For other cases packet will be created on host and don't

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 10:17:27PM +0100, Bruce Simpson wrote: > On 20/08/16 21:41, Slawa Olhovchenkov wrote: > > On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > >> So, Ryan -- your original reading of how in_broadcast() behaves is > >> correct, modulo the all-ones bypassing it.

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 22:17, Bruce Simpson wrote: However, we still have to keep the FreeBSD-on-Ethernet ship sailing smoothly. The intent of the original input path change is clearly for performance, but perhaps slipping the M_BCAST tag in the stack is the right way forward. I would also suggest: we add

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 21:41, Slawa Olhovchenkov wrote: On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: So, Ryan -- your original reading of how in_broadcast() behaves is correct, modulo the all-ones bypassing it. What purpose to analyse L2 header? I was just checking for possible edge

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > On 20/08/16 21:05, Bruce Simpson wrote: > > Unless I am missing something crucial here? As far as I can tell, > > arpresolve() unconditionally resolves L2 next-hop to the value of > > ifp->if_broadcastaddr. And that is always set to

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 21:05, Bruce Simpson wrote: Unless I am missing something crucial here? As far as I can tell, arpresolve() unconditionally resolves L2 next-hop to the value of ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by default for Ethernet ifnets: FF:FF:FF:FF:FF:FF.

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 19:57, Ryan Stone wrote: On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov > wrote: You also can recive this on ethernet too, IMHO, in case of /32. Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be relaxed

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 02:57:36PM -0400, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov wrote: > > > You also can recive this on ethernet too, IMHO, in case of /32. > > Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be > > relaxed

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov wrote: > You also can recive this on ethernet too, IMHO, in case of /32. > Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be > relaxed on this. > There is no broadcast address on a /32 network. Independent

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 02:02:16PM -0400, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: > > > For host enought have [hidden] alias with broadcsts bits. > > Anyway, don't should relay on the L2 information, you can recive L3 > > unicast addressed

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 2:09 PM, Adrian Chadd wrote: > Hi, > > So why not fix those paths? > > > > -adrian > Is there even a fix that can be done there? I wouldn't expect a point-to-point protocol like PPP to have any need to explicitly signal that a packet is a broadcast.

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 19:09, Adrian Chadd wrote: On 20 August 2016 at 11:02, Ryan Stone wrote: On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: For host enought have [hidden] alias with broadcsts bits. Anyway, don't should relay on the L2 information, you

Re: svn commit: r304436 - in head: . sys/netinet

On 20 August 2016 at 11:02, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: >> >> For host enought have [hidden] alias with broadcsts bits. >> Anyway, don't should relay on the L2 information, you can recive L3 >> unicast

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: > For host enought have [hidden] alias with broadcsts bits. > Anyway, don't should relay on the L2 information, you can recive L3 > unicast addressed packets (with alien dst IP address) in L2 broadcas > packet. > This

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 18:30, Slawa Olhovchenkov wrote: Anyway, don't should relay on the L2 information, you can recive L3 unicast addressed packets (with alien dst IP address) in L2 broadcas packet. That is exactly what the egress routers in chapter 6 of my PhD do, but in a very controlled way -- by

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 12:36:58PM -0400, Ryan Stone wrote: > + adrian@, who prompted me to look at UDP in the first place > > > I'm really not sure what my next step should be. I'm willing to revert > r304436, but I really don't want to revert r304437 because we've seen > crashes in the real

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 17:49, Bruce Simpson wrote: - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 17:36, Ryan Stone wrote: + adrian@, who prompted me to look at UDP in the first place I'm really not sure what my next step should be. I'm willing to revert r304436, but I really don't want to revert r304437 because we've seen crashes in the real world due to the missing locking.

Re: svn commit: r304436 - in head: . sys/netinet

+ adrian@, who prompted me to look at UDP in the first place I'm really not sure what my next step should be. I'm willing to revert r304436, but I really don't want to revert r304437 because we've seen crashes in the real world due to the missing locking. Unfortunately, reverting r304436 would

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 17:27, Bruce Simpson wrote: Alternatively, the L2 destination MAC may be rewritten for that specific address, to avoid the destination being interpreted by routers in the Metro Ethernet core. s/routers/switches/ -- in some views of the world, they are the same :) PBB is also known

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 16:42, Bruce Simpson wrote: On 20/08/16 16:27, Ryan Stone wrote: Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 16:27, Ryan Stone wrote: Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after all, not Infernal-ethernet-extension

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 11:01 AM, Bruce Simpson wrote: > tun(4) on the other hand is a plain, PPP-like, IP tunnel. > Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. But this mbuf flag is not guaranteed to be set in all

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 15:52, Ryan Stone wrote: It is perfectly legal for broadcast packets to be addressed to the end of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the situation may be readily

Re: svn commit: r304436 - in head: . sys/netinet

On Sat, Aug 20, 2016 at 7:48 AM, Bruce Simpson wrote: > It is perfectly legal for broadcast packets to be addressed to the end of > a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The > classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the >

Re: svn commit: r304436 - in head: . sys/netinet

On 20/08/16 12:33, Bruce Simpson wrote: This potentially breaks reception of IPv4 broadcasts where FreeBSD is the endpoint at the end of a P2P interface, or other forms of links, where there is no guarantee that the link layer will set M_BCAST (or indeed M_MCAST). I appreciate it probably

Re: svn commit: r304436 - in head: . sys/netinet

This potentially breaks reception of IPv4 broadcasts where FreeBSD is the endpoint at the end of a P2P interface, or other forms of links, where there is no guarantee that the link layer will set M_BCAST (or indeed M_MCAST). On 18/08/16 23:59, Ryan Stone wrote: Author: rstone Date: Thu Aug

Re: svn commit: r304436 - in head: . sys/netinet

On Thu, 18 Aug 2016 22:59:05 + Ryan Stone wrote: > Author: rstone > Date: Thu Aug 18 22:59:05 2016 > New Revision: 304436 > URL: https://svnweb.freebsd.org/changeset/base/304436 > > Log: > Don't check for broadcast IPs on non-bcast pkts > > in_broadcast() can be

svn commit: r304436 - in head: . sys/netinet

Author: rstone Date: Thu Aug 18 22:59:05 2016 New Revision: 304436 URL: https://svnweb.freebsd.org/changeset/base/304436 Log: Don't check for broadcast IPs on non-bcast pkts in_broadcast() can be quite expensive, so skip calling it if the incoming mbuf wasn't sent to a broadcast L2