Chelsio T520-SO-CR low performance (netmap tested) for RX

Luigi Rizzo rizzo at iet.unipi.it
Sat Jan 23 19:12:31 UTC 2016


On Sat, Jan 23, 2016 at 10:38 AM, Navdeep Parhar <nparhar at gmail.com> wrote:
> On Sat, Jan 23, 2016 at 03:48:39PM -0200, Marcus Cenzatti wrote:
> ...
>>
>> woops, my bad, yes probably we had some drop, with -S and -D now I get 1.2Mpps.
>
> Run "netstat -hdw1 -i cxl<n>" on the receiver during your test.

Navdeep, does this give any info on the ncxl port rather
than the cxl port connected to the host stack ?

...
> Do you know if the transmitter will pad up so as not to put runts on the
> wire?  If not then you might want to bump up the size of the frame
> explicitly (there's some pkt-gen knob for this).
>

ix/ixl do automatic padding, and in any case pkt-gen
by default generates valid packet sizes (and so it does
with the variable-size tests I suggested).

Is there any parameter that controls interrupt moderation ?

In any case we need to know the numbers when sending to the
ncxl MAC address as opposed to broadcast.

I suspects one of these problems:

- the interrupt moderation interval is too long thus limiting
  the rate to one ring/interval. Unlikely though, even
  with 1k slots, the measured 1.2 Mpps corresponds to almost
  1ms which is too long

- the receiver cannot cope with the input load and somehow
  takes a long time to recover from congestion. If this is
  the case, running the sender at a lower rate might reach
  a peak throughput > 1.2 Mpps when the receiver can still
  keep up, and then drop to the low rate under congestion.

- and of course bus errors, when the device is connected on
  a PCIe slot with only 1-2 data lanes.
  This actually happens a lot, physical connector sizes
  do not reflect the number of active PCIe lanes.

cheers
luigi


More information about the freebsd-net mailing list