: "Slawa Olhovchenkov" , "Hans Petter Selasky"
, "Adrian Chadd" ,
src-committ...@freebsd.org, "Ian Lepore" ,
svn-src-...@freebsd.org, svn-src-head@freebsd.org, "Fabien Thomas"
Envoyé: Mardi 31 Mars 2015 00:38:36
Objet: Re: svn commit: r280759 -
On Mon, Mar 30, 2015 at 06:20:45PM +0200, Emeric POUPON wrote:
E> Yes, sure!
E>
E> I will test it tomorrow and tell you the results.
E> However, keep in mind I did not see any performance impact with the previous
patch.
I created a patch that enables RFC6864 and per-CPU ip_id for those packets,
On Mon, Mar 30, 2015 at 06:20:45PM +0200, Emeric POUPON wrote:
E> Yes, sure!
E>
E> I will test it tomorrow and tell you the results.
E> However, keep in mind I did not see any performance impact with the previous
patch.
This is expectable, since
a) foo++ is almost as bad to cache as atomic_add(
r Selasky"
, "Adrian Chadd" ,
src-committ...@freebsd.org, "Ian Lepore" ,
svn-src-...@freebsd.org, svn-src-head@freebsd.org, "Fabien Thomas"
Envoyé: Lundi 30 Mars 2015 17:27:07
Objet: Re: svn commit: r280759 - head/sys/netinet
On Mon, Mar 30, 2015 at 05:23:48P
On Mon, Mar 30, 2015 at 05:23:48PM +0200, Emeric POUPON wrote:
E> Hello,
E>
E> Sorry for late response, I didn't notice this issue was discussed here.
E>
E> In one of our tests, we have several (up to 12) cpu that emit packets with
the same src, dst and protocol to a remote host.
E> We did this
reebsd.org, "Gleb Smirnoff"
, svn-src-head@freebsd.org, "Fabien Thomas"
Envoyé: Lundi 30 Mars 2015 16:16:17
Objet: Re: svn commit: r280759 - head/sys/netinet
On Mon, Mar 30, 2015 at 03:45:00PM +0200, Hans Petter Selasky wrote:
> Gleb,
>
> On 03/30/15 14:59,
On Mon, Mar 30, 2015 at 03:45:00PM +0200, Hans Petter Selasky wrote:
> Gleb,
>
> On 03/30/15 14:59, Hans Petter Selasky wrote:
> > On 03/30/15 14:51, Gleb Smirnoff wrote:
> >>Hans,
> >>
> >
> > Gleb: Can you answer my question first:
> >
> > Should the 16-bit IP ID field carry any useful info
Gleb,
On 03/30/15 14:59, Hans Petter Selasky wrote:
On 03/30/15 14:51, Gleb Smirnoff wrote:
Hans,
Gleb: Can you answer my question first:
Should the 16-bit IP ID field carry any useful information or not?
Yes:
An identifying value assigned by the sender to aid in assembling the
On Mon, Mar 30, 2015 at 02:59:16PM +0200, Hans Petter Selasky wrote:
H> Gleb: Can you answer my question first:
H>
H> Should the 16-bit IP ID field carry any useful information or not?
Yes:
An identifying value assigned by the sender to aid in assembling the
fragments of a datagram.
--
On 03/30/15 14:51, Gleb Smirnoff wrote:
Hans,
Gleb: Can you answer my question first:
Should the 16-bit IP ID field carry any useful information or not?
On Mon, Mar 30, 2015 at 02:38:12PM +0200, Hans Petter Selasky wrote:
H> > DELAY() into network stack? Are you serious now or kidding me
Hans,
On Mon, Mar 30, 2015 at 02:38:12PM +0200, Hans Petter Selasky wrote:
H> > DELAY() into network stack? Are you serious now or kidding me?
H>
H> If there should be any useful meaning in the 16-bit IP ID field, the
H> value can't be allowed to wrap several times in a millisecond. Given the
On 03/30/15 14:07, Gleb Smirnoff wrote:
Hans,
On Mon, Mar 30, 2015 at 01:29:51PM +0200, Hans Petter Selasky wrote:
H> You don't get it fully. Every time a CPU runs out of IDs, it allocates a
H> new 256 long series of numbers. That way the CPUs allocate numbers in
H> sequence.
H>
H> > The sugg
Hans,
On Mon, Mar 30, 2015 at 01:29:51PM +0200, Hans Petter Selasky wrote:
H> You don't get it fully. Every time a CPU runs out of IDs, it allocates a
H> new 256 long series of numbers. That way the CPUs allocate numbers in
H> sequence.
H>
H> > The suggested code suffers from migration more t
On 03/30/15 12:59, Gleb Smirnoff wrote:
On Mon, Mar 30, 2015 at 10:51:51AM +0200, Hans Petter Selasky wrote:
H> Hi,
H>
H> Like was mentioned here, maybe we need a global counter that is not
H> accessed that frequently, and use per-cpu counters for the most frequent
H> accesses. To keep the order
On Mon, Mar 30, 2015 at 10:51:51AM +0200, Hans Petter Selasky wrote:
H> Hi,
H>
H> Like was mentioned here, maybe we need a global counter that is not
H> accessed that frequently, and use per-cpu counters for the most frequent
H> accesses. To keep the order somewhat sane, we need a global counter
Hi,
Like was mentioned here, maybe we need a global counter that is not
accessed that frequently, and use per-cpu counters for the most frequent
accesses. To keep the order somewhat sane, we need a global counter:
Pseudo code:
static int V_ip_id;
PER_CPU(V_ip_id_start);
PER_CPU(V_ip_id_end)
On Sun, 29 Mar 2015, Ian Lepore wrote:
On Mon, 2015-03-30 at 00:07 +0300, Gleb Smirnoff wrote:
On Sun, Mar 29, 2015 at 08:16:46AM -0700, Adrian Chadd wrote:
A> On 29 March 2015 at 01:13, Hans Petter Selasky wrote:
A> > On 03/28/15 20:16, Gleb Smirnoff wrote:
A> >>
A> >> +uint16_t
A> >> +ip_new
On Mon, 2015-03-30 at 00:07 +0300, Gleb Smirnoff wrote:
> On Sun, Mar 29, 2015 at 08:16:46AM -0700, Adrian Chadd wrote:
> A> On 29 March 2015 at 01:13, Hans Petter Selasky wrote:
> A> > On 03/28/15 20:16, Gleb Smirnoff wrote:
> A> >>
> A> >> +uint16_t
> A> >> +ip_newid(void)
> A> >> +{
> A> >> +
>
On Sun, Mar 29, 2015 at 02:15:43PM -0700, Adrian Chadd wrote:
A> > To illustrate the probability of 1 instruction race, I would suggest to
A> > look at PCPU_ADD() implementation for all arches except amd64/i386 and
A> > find out that it is prone to this race. Hitting the race in PCPU_ADD()
A> > wil
On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote:
J> > J> > I think we can use per-cpu ID counters, each CPU incrementing its
J> > J> > own. If we start with random values, then probability of two packets
with
J> > J> > the same ID emitting at the allowed timeframe will be acceptab
> To illustrate the probability of 1 instruction race, I would suggest to
> look at PCPU_ADD() implementation for all arches except amd64/i386 and
> find out that it is prone to this race. Hitting the race in PCPU_ADD()
> will usually lead to mangling vm_meter statistics. Did we ever observe
> this
On Sun, Mar 29, 2015 at 08:16:46AM -0700, Adrian Chadd wrote:
A> On 29 March 2015 at 01:13, Hans Petter Selasky wrote:
A> > On 03/28/15 20:16, Gleb Smirnoff wrote:
A> >>
A> >> +uint16_t
A> >> +ip_newid(void)
A> >> +{
A> >> +
A> >> + counter_u64_add(V_ip_id, 1);
A> >> + return (htons((*
On 29 March 2015 at 01:13, Hans Petter Selasky wrote:
> On 03/28/15 20:16, Gleb Smirnoff wrote:
>>
>> +uint16_t
>> +ip_newid(void)
>> +{
>> +
>> + counter_u64_add(V_ip_id, 1);
>> + return (htons((*(uint64_t *)zpcpu_get(V_ip_id)) & 0x));
>> +}
>
>
> Technically you would need to ent
On 03/28/15 20:16, Gleb Smirnoff wrote:
+uint16_t
+ip_newid(void)
+{
+
+ counter_u64_add(V_ip_id, 1);
+ return (htons((*(uint64_t *)zpcpu_get(V_ip_id)) & 0x));
+}
Technically you would need to enter a critical section here, so that the
current process doesn't get swapped to a d
On Sat, Mar 28, 2015 at 11:22:16PM -0400, Benjamin Kaduk wrote:
> On Sat, Mar 28, 2015 at 9:15 PM, John-Mark Gurney wrote:
>
> > Slawa Olhovchenkov wrote this message on Sun, Mar 29, 2015 at 00:34 +0300:
> > > On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote:
> > >
> > > In this
On Sat, Mar 28, 2015 at 9:15 PM, John-Mark Gurney wrote:
> Slawa Olhovchenkov wrote this message on Sun, Mar 29, 2015 at 00:34 +0300:
> > On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote:
> >
> > In this case may be do range allocation of ID (per-CPU)?
> > For example, allocate 12
Slawa Olhovchenkov wrote this message on Sun, Mar 29, 2015 at 00:34 +0300:
> On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote:
>
> > > On Sat, Mar 28, 2015 at 10:23:13AM -0700, John-Mark Gurney wrote:
> > > J> Please read:
> > > J> https://tools.ietf.org/html/rfc6864
> >
> > Anywa
On Sat, Mar 28, 2015 at 01:43:33PM -0700, John-Mark Gurney wrote:
> Gleb Smirnoff wrote this message on Sat, Mar 28, 2015 at 21:18 +0300:
> > On Sat, Mar 28, 2015 at 10:23:13AM -0700, John-Mark Gurney wrote:
> > J> > On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
> > J> > F> Author
Gleb Smirnoff wrote this message on Sat, Mar 28, 2015 at 21:18 +0300:
> On Sat, Mar 28, 2015 at 10:23:13AM -0700, John-Mark Gurney wrote:
> J> > On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
> J> > F> Author: fabient
> J> > F> Date: Fri Mar 27 13:26:59 2015
> J> > F> New Revision:
On Sat, Mar 28, 2015 at 11:34:43AM +0300, Gleb Smirnoff wrote:
T> On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
T> F> Author: fabient
T> F> Date: Fri Mar 27 13:26:59 2015
T> F> New Revision: 280759
T> F> URL: https://svnweb.freebsd.org/changeset/base/280759
T> F>
T> F> Log:
T> F>
On Sat, Mar 28, 2015 at 10:23:13AM -0700, John-Mark Gurney wrote:
J> > On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
J> > F> Author: fabient
J> > F> Date: Fri Mar 27 13:26:59 2015
J> > F> New Revision: 280759
J> > F> URL: https://svnweb.freebsd.org/changeset/base/280759
J> > F>
J>
> On 28 Mar 2015, at 17:23 , John-Mark Gurney wrote:
>
> Gleb Smirnoff wrote this message on Sat, Mar 28, 2015 at 11:34 +0300:
>> On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
>> F> Author: fabient
>> F> Date: Fri Mar 27 13:26:59 2015
>> F> New Revision: 280759
>> F> URL: https:
Gleb Smirnoff wrote this message on Sat, Mar 28, 2015 at 11:34 +0300:
> On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
> F> Author: fabient
> F> Date: Fri Mar 27 13:26:59 2015
> F> New Revision: 280759
> F> URL: https://svnweb.freebsd.org/changeset/base/280759
> F>
> F> Log:
> F>
On Fri, Mar 27, 2015 at 01:26:59PM +, Fabien Thomas wrote:
F> Author: fabient
F> Date: Fri Mar 27 13:26:59 2015
F> New Revision: 280759
F> URL: https://svnweb.freebsd.org/changeset/base/280759
F>
F> Log:
F> On multi CPU systems, we may emit successive packets with the same id.
F> Fix the r
Author: fabient
Date: Fri Mar 27 13:26:59 2015
New Revision: 280759
URL: https://svnweb.freebsd.org/changeset/base/280759
Log:
On multi CPU systems, we may emit successive packets with the same id.
Fix the race by using an atomic operation.
Differential Revision:https://reviews.fr
35 matches
Mail list logo
