Slow performance with Intel X540-T2 10Gb NIC

[hiren panchasara]

On 07/22/16 at 11:23P, Kevin Oberman wrote:
[skip]
> 
> This sort of problem can be very tricky to diagnose. I'd like to suggest
> that one of the tool you use should be  SIFTR. It does kernel level
> collection of network statistics and is a loadable module. By default it i
> IPv4 only. It will have to be re-built with "CFLAGS+=-DSIFTR_IPV6"
> uncommented in /sys/modules/siftr/Makefile for IPv6 support. It starts,
> stops, amd manages collection under the control of 4 sysctls.
> 
> I have found it invaluable for analysis of netork performance issues, but
> seems to not be widely known.

Another such tool which I (personally) find more powerful and less known
is dtrace in this context.

For example, in output direction, right when tcp is about to send a
packet to ip, there is a dtrace trace point which you can use to get a
ton of useful information:

# dtrace -n 'tcp:::send / args[2]->ip_saddr == "192.168.0.1" / {printf ("%8u", args[3]->tcps_mss)}'

This can let me see MSS for that out going packet. You can see all of
tcp control block data this way. The mapping is in /usr/lib/dtrace/tcp.d
file. You can always add whatever you want in there and use it.

https://github.com/brendangregg/DTrace-book-scripts/blob/master/Chap6/tcpio.d
is one such awesome script that you can modify to match your needs and
look at whatever bidirectional traffic in detail.

With dtrace predicates, you can filter out what you want to log which is
not possible yet with siftr. This makes running siftr a little annoying
on a busy box as it logs all the things and you have to do post
processing to get what you want to see.

Just my 2 rupees.

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20160723/230e98ac/attachment.sig>