Am I reading this correctly, in that polling for receive packets is only
used if the NIC has more than a single rx ring?
Most of the commonly available NICs only have a single receive ring.
(Exceptions are nxge, ce, some models of bge, bnx, and certain Intel
NICs.) Notably the e1000g devices found on current niagra hardware only
have a single receive ring.
When the rx ring gets overfull, it would be nice to be able to
dynamically switch to polling somehow.
-- Garrett
Sunay Tripathi wrote:
> Guys,
>
> We have a basic implementation in place for this work
> http://www.opensolaris.org/os/project/crossbow/Design_softringset.txt
>
> Basically the idea is to keep the data paths very tight, always do
> Dynamic polling when possible (independent of the workloads) while
> utilizing more than 1 CPU for parallelizing the work load. As part of
> this work, I am trying to see what can be done for small packet
> forwarding performance and also latency (btw there are two projects
> coming online soon to specifically target forwarding and latrency).
>
> So if people have needs/suggestions/stakes in this area, I would
> recommend reading the above document and dive in. As for how to
> test some of these things, you can use 'ttcp'
> (http://sd.wareonearth.com/~phil/net/ttcp/) on a back to back
> setup for starters (10Gb NICs might be better). Use the '-D' option
> with small write (64 bytes) to disable nagle and actually send
> small packets on the wire.
>
> What I typically use
> server: ./ttcp -s -r -v -u -b 262144 -l 64 -n 500000
> client: ./ttcp -D -s -v -u -t <hostname> -b 262144 -l 64 -n 500000
>
> This is with UDP and if you snoop the wire, you will see the small
> packets going by.
>
> Cheers,
> Sunay
>
>
