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
>
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
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
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
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
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
On Sun, Aug 28, 2016 at 10:20:08AM -0700, Adrian Chadd wrote:
Hi,
thanks for answer!
> 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
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,
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
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
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()] =
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-all@freebsd.org mailing list
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
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
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:
> >
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
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
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
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
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
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
[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-all@freebsd.org mailing list
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
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
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
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.
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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.
+ 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
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
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
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
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
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
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
>
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
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
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
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
53 matches
Mail list logo