svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf

[Hans Petter Selasky]

On 04/02/15 19:49, Hans Petter Selasky wrote:
> On 04/02/15 18:00, Robert Watson wrote:
>> On Thu, 2 Apr 2015, Mateusz Guzik wrote:
>>
>>>> If you carefully read the thread I referred to, you would notice that
>>>> on many arches, save amd64 and i386, all systems stats are prone to
>>>> mangling the stats due to migration within PCPU_INC. Look here:
>>>>
>>>> grep '^#define    PCPU_ADD' sys/*/include/pcpu.h
>>>>
>>>> Do we have reports on not precise enough statistics, yet?
>>>
>>> How many non-x86 installations with multiple cpus and high traffic are
>>> out there?
>>
>> Not sure if this was a rhetorical question or not, but: quite a few.  We
>> have support for several highly threaded 64-bit MIPS systems including
>> those from Cavium and Broadcom (was NetLogic Micro was RMI).  Several
>> reference systems are in the netperf cluster including 16- and 32-thread
>> systems normally deployed in high-performance network products.  It's
>> possible that ARMv8 systems will gradually displayce 64-bit MIPS systems
>> in this arena in the future, but hard to say.  Either way, it's not x86.
>> :-)
>>
>
> Hi,
>
> I've sketched up my proposal here, please have a look.
>
> https://reviews.freebsd.org/D2211
>
> --HPS
>

Hi,

In my sketchup I assume that packets for the same destination will not 
be re-ordered. I see that the current ip_reass() code does not care 
about TCP or UDP port numbers at all. Maybe we should add code to check 
that the packet belongs to the same ports too?

Does somebody here know what happens in these two cases:

If we are transmitting using TSO, will the network adapter increment the 
IP ID field somehow? What happens if an outgoing IP packet resulting 
from a TSO packet get fragmented by a router?

In ip_fragment() when we create fragments we should increment the ip_id 
value for each fragment?

--HPS