When sgifford mentioned tcpdump it reminded me: on a normal Ethernet segment, the MTU (maximum size of a packet) is customarily set to 1500 bytes. You could probably make the internal workings of NFS more efficient by raising the MTU, which will reduce the number of packets.

Be wary of the following, though:

(1) routing packets from a circuit with a large MTU to a circuit with a smaller one can cause occasional odd problems; for example distant web sites behind firewalls that block ICMP "path MTU exceeded" messages may not be able to send you pages more than 1500 bytes long any more. You may need to keep the NFS between your client and the servers on an isolated network to avoid this kind of problem. The client and servers could have interfaces to other networks in order to talk to your other equipment, as long as traffic isn't routed between the networks.

(2) You need jumbo or giant frame support, which is only common on Gigabit and faster Ethernet. Note that there is no vendor-independent standard for exact how big a jumbo frame can be, but Cisco suggests 9216 bytes.

It's very difficult to generalize about how much jumbo packets really help, because there is so much variation in how much of the overhead of breaking up data into multiple packets and then reassembling it can be offloaded onto dedicated hardware. But if you have the appropriate switches and NIC cards, it might be worth a quick benchmark.

As a starting point, HP ran a benchmark of 9000 vice 1500 byte MTU on GigE, and showed around 43% better throughput and around 27% less CPU on the receive side and 43% less CPU on the transmit site.