svn commit: r280759 - head/sys/netinet

[Emeric POUPON]

Hello,

Sorry for late response, I didn't notice this issue was discussed here.

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.
We did this patch since we observed bad packet reassembly on the remote host, due to different fragments emitted with the same ip id.
It was an IPsec test (emitting ESP packets) but I guess we could easily reproduce this problem using several "ping -i 0 -s BIG_SIZE_HERE DST" commands running in parallel.

Even if we reached something like 1M pps, it is likely that we did not see any performance penalty since the IPsec stack is quite time consuming.
Now, the question is: is there a real performance issue here or is it likely to be hidden by other problems?

If it is a real problem, maybe an acceptable tradeoff would be to make the counter per CPU and:
- initialize it with the cpu id,
- increment it by the number of cpus.

What do you think?

Best Regards,

Emeric

----- Mail original -----
De: "Slawa Olhovchenkov" <slw at zxy.spb.ru>
À: "Hans Petter Selasky" <hps at selasky.org>
Cc: "Adrian Chadd" <adrian at freebsd.org>, src-committers at freebsd.org, "Ian Lepore" <ian at freebsd.org>, svn-src-all at freebsd.org, "Gleb Smirnoff" <glebius at FreeBSD.org>, svn-src-head at freebsd.org, "Fabien Thomas" <fabient at freebsd.org>
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, 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
> >     fragments of a datagram.
> 
> The numbering should be somewhat sane and when you are suggesting that a 
> multi-line function and cache line issues will hit the system hard, 
> which I don't doubt, functions like "unrhdr()" are probably out of the 
> question?
> 
> >> Let me ask again: are you serious? Do you suggest to delay transmitting
> >> network packets with a DELAY()?
> 
> Yes! It doesn't have to be done by the software. It can be done by the 
> ethernet hardware too!
> 
> >>
> >> H> Or maybe we can add an IPv4 option to escape a 32-bit IP ID field and
> >> H> don't use the 16-bit IP ID field.
> >>
> >> Is that also serious? Do you suggest to change layout of IP packet?
> >>
> 
> IPv4 packets can carry additional options which is part of the standard 
> IPv4 packet layout, though routers which perform fragmentation would 
> need to support it ...
> 
> 
> Does this discussion mean that IPv4 traffic which is subject to 
> fragmentation has a transmission rate limit depending on the roundtrip 
> time to avoid risking bad defragmentation issues?

You can't be know about needing fragmenatation.
Fragmentation occur on remote transit routers, w/o information packet
source.
Any packet (w/o DF) can be fragmented.
In some cases pakets one flow can be dispatched by different path and
fragmented only on the one path.
_______________________________________________
svn-src-all at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe at freebsd.org"