* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Bill Fink @ 2011-03-11 2:25 UTC (permalink / raw)
To: Lucas Nussbaum
Cc: Stephen Hemminger, Injong Rhee, David Miller, xiyou wangcong,
netdev, sangtae ha
In-Reply-To: <20110310085433.GA11953@xanadu.blop.info>
On Thu, 10 Mar 2011, Lucas Nussbaum wrote:
> On 10/03/11 at 02:17 -0500, Bill Fink wrote:
> > On Wed, 9 Mar 2011, Stephen Hemminger wrote:
> >
> > > Bill what is the HZ in your kernel config.
> > > I am concerned hystart doesn't work well with HZ=100
> >
> > HZ=1000
> >
> > But I did have tcp_timestamps disabled. Should I re-run
> > the tests with tcp_timestamps enabled?
>
> I ran my tests with timestamps enabled and HZ=250. If you have the
> opportunity to run tests in the same config, it would be great. The
> HZ=250 vs HZ=1000 difference could explain why it's working.
>
> However, enabling or disabling timestamps shouldn't make a difference,
> since the hystart code doesn't use TCP_CONG_RTT_STAMP.
I reran the same tests with HZ=250 and tcp_timestamps enabled.
BTW all my tests are with 9000-byte jumbo frames. If you want,
I can also try them using standard 1500-byte Ethernet frames.
First on the 18 ms RTT path:
8 GB transfer across an 18 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
614.5625 MB / 1.00 sec = 5155.1383 Mbps 0 retrans
824.2500 MB / 1.00 sec = 6914.5038 Mbps 0 retrans
826.6875 MB / 1.00 sec = 6934.5632 Mbps 0 retrans
831.5625 MB / 1.00 sec = 6975.7146 Mbps 0 retrans
835.1875 MB / 1.00 sec = 7006.1867 Mbps 0 retrans
844.8125 MB / 1.00 sec = 7086.7867 Mbps 0 retrans
862.1250 MB / 1.00 sec = 7231.9274 Mbps 0 retrans
886.5625 MB / 1.00 sec = 7437.0402 Mbps 0 retrans
918.6875 MB / 1.00 sec = 7706.5633 Mbps 0 retrans
8192.0000 MB / 9.80 sec = 7009.7460 Mbps 12 %TX 31 %RX 0 retrans 18.91 msRTT
Ramps up quickly to a little under 7 Gbps, then increases more
slowly to 7.7 Gbps, with no TCP retransmissions. Actually performed
somewhat better than the HZ=1000 case.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and hystart:
i7test7% nuttcp -n8g -i1 -w40m 192.168.1.23
716.0000 MB / 1.00 sec = 6006.0812 Mbps 0 retrans
864.5000 MB / 1.00 sec = 7251.9589 Mbps 0 retrans
866.1250 MB / 1.00 sec = 7265.4596 Mbps 0 retrans
871.1250 MB / 1.00 sec = 7307.7746 Mbps 0 retrans
875.6250 MB / 1.00 sec = 7345.2308 Mbps 0 retrans
886.1875 MB / 1.00 sec = 7433.8796 Mbps 0 retrans
904.1250 MB / 1.00 sec = 7584.3654 Mbps 0 retrans
929.1875 MB / 1.00 sec = 7794.4728 Mbps 0 retrans
961.6250 MB / 1.00 sec = 8066.7839 Mbps 0 retrans
8192.0000 MB / 9.34 sec = 7356.7856 Mbps 13 %TX 32 %RX 0 retrans 18.92 msRTT
Ramps up quickly to 7+ Gbps, then increases more slowly to 8+ Gbps,
with no TCP retransmissions. Performed significantly worse than
the HZ=1000 case.
8 GB transfer across an 18 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
850.8750 MB / 1.00 sec = 7137.3642 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.3396 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.5486 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.5883 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.0621 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.4396 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.5189 Mbps 0 retrans
8192.0000 MB / 7.23 sec = 9499.4276 Mbps 17 %TX 40 %RX 0 retrans 18.95 msRTT
Quickly ramps up to full 10-GigE line rate, with no TCP retrans.
Same performance as HZ=1000 case.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -i1 -w40m 192.168.1.23
969.8125 MB / 1.00 sec = 8135.2793 Mbps 0 retrans
1181.1250 MB / 1.00 sec = 9908.0541 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.1810 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.9044 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0729 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.0532 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.9549 Mbps 0 retrans
8192.0000 MB / 7.15 sec = 9609.9893 Mbps 17 %TX 41 %RX 0 retrans 18.92 msRTT
Also quickly ramps up to full 10-GigE line rate, with no TCP retrans.
Same performance as HZ=1000 case.
Now trying the same type of tests across an 80 ms RTT path.
8 GB transfer across an 80 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
10.6250 MB / 1.00 sec = 89.1274 Mbps 0 retrans
501.7500 MB / 1.00 sec = 4208.6979 Mbps 0 retrans
872.9375 MB / 1.00 sec = 7323.2651 Mbps 0 retrans
865.5000 MB / 1.00 sec = 7259.8901 Mbps 0 retrans
854.9375 MB / 1.00 sec = 7172.0224 Mbps 0 retrans
872.0000 MB / 1.00 sec = 7314.8735 Mbps 0 retrans
866.6875 MB / 1.00 sec = 7270.3017 Mbps 0 retrans
855.1250 MB / 1.00 sec = 7172.9354 Mbps 0 retrans
868.7500 MB / 1.00 sec = 7288.1352 Mbps 0 retrans
868.3750 MB / 1.00 sec = 7283.8238 Mbps 0 retrans
8192.0000 MB / 10.99 sec = 6250.8745 Mbps 11 %TX 25 %RX 0 retrans 80.78 msRTT
Similar to the 20 ms RTT path, but achieving somewhat lower
performance levels, presumably due to the larger RTT. Ramps
up fairly quickly to 7+ Gbps, then appears to stabilize at
that level, with no TCP retransmissions. Somewhat better
performance than the HZ=1000 case.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and hystart:
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.8197 Mbps 0 retrans
1071.6875 MB / 1.00 sec = 8989.8315 Mbps 0 retrans
1089.6250 MB / 1.00 sec = 9140.6929 Mbps 0 retrans
1093.4375 MB / 1.00 sec = 9172.4186 Mbps 0 retrans
1095.1875 MB / 1.00 sec = 9187.1262 Mbps 0 retrans
1094.7500 MB / 1.00 sec = 9183.3460 Mbps 0 retrans
1097.8750 MB / 1.00 sec = 9208.9431 Mbps 0 retrans
1103.9375 MB / 1.00 sec = 9261.2584 Mbps 0 retrans
8192.0000 MB / 8.48 sec = 8102.4984 Mbps 15 %TX 38 %RX 0 retrans 80.81 msRTT
Quickly ramps up to 9 Gbps and then slowly increases further,
with no TCP retrans. Basically same performance as HZ=1000 case.
8 GB transfer across an 80 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
10.0000 MB / 1.00 sec = 83.8847 Mbps 0 retrans
482.3125 MB / 1.00 sec = 4045.8172 Mbps 0 retrans
863.2500 MB / 1.00 sec = 7241.4224 Mbps 0 retrans
874.3750 MB / 1.00 sec = 7334.7304 Mbps 0 retrans
855.0000 MB / 1.00 sec = 7172.3889 Mbps 0 retrans
863.6250 MB / 1.00 sec = 7244.6840 Mbps 0 retrans
875.0625 MB / 1.00 sec = 7340.5489 Mbps 0 retrans
855.1875 MB / 1.00 sec = 7173.6390 Mbps 0 retrans
863.8750 MB / 1.00 sec = 7246.9044 Mbps 0 retrans
873.3125 MB / 1.00 sec = 7325.9788 Mbps 0 retrans
8192.0000 MB / 10.99 sec = 6253.7478 Mbps 11 %TX 26 %RX 0 retrans 80.80 msRTT
Ramps up quickly to 7+ Gbps, then appears to stabilize at that
level, with no TCP retransmissions. Performance is same as
with autotuning enabled, but less than using a manually set
100 MB socket buffer. Same performance as HZ=1000 case.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.7945 Mbps 0 retrans
1148.4375 MB / 1.00 sec = 9633.6860 Mbps 0 retrans
1176.9375 MB / 1.00 sec = 9872.7291 Mbps 0 retrans
1088.1250 MB / 1.00 sec = 9127.4342 Mbps 39 retrans
171.0625 MB / 1.00 sec = 1435.1370 Mbps 0 retrans
901.0625 MB / 1.00 sec = 7558.3275 Mbps 0 retrans
1160.0625 MB / 1.00 sec = 9731.1831 Mbps 0 retrans
1172.5625 MB / 1.00 sec = 9836.5508 Mbps 0 retrans
1085.0625 MB / 1.00 sec = 9101.2174 Mbps 31 retrans
150.3750 MB / 1.00 sec = 1261.5908 Mbps 2 retrans
28.1875 MB / 1.00 sec = 236.4544 Mbps 0 retrans
8192.0000 MB / 11.31 sec = 6077.0651 Mbps 14 %TX 29 %RX 72 retrans 80.82 msRTT
As in the HZ=1000 case, disabling hystart on a large RTT path
does not seem to play nice with a manually specified socket buffer,
resulting in TCP retransmissions that limit the effective network
performance. Performance seems similar to the HZ=1000 case.
This is a repeatable phenomenon, but didn't seem quite as
variable as in the HZ=1000 case (but probably need a larger
number of repetitions to draw any firm conclusions about that).
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.4375 MB / 1.00 sec = 867.6472 Mbps 0 retrans
1143.0625 MB / 1.00 sec = 9589.1347 Mbps 0 retrans
629.4375 MB / 1.00 sec = 5280.0886 Mbps 24 retrans
164.8750 MB / 1.00 sec = 1383.0759 Mbps 0 retrans
1121.6250 MB / 1.00 sec = 9408.7878 Mbps 0 retrans
1168.1250 MB / 1.00 sec = 9799.0309 Mbps 0 retrans
1167.5000 MB / 1.00 sec = 9793.5725 Mbps 0 retrans
1165.9375 MB / 1.00 sec = 9780.0841 Mbps 0 retrans
959.8750 MB / 1.00 sec = 8052.4902 Mbps 9 retrans
568.1250 MB / 1.00 sec = 4765.8065 Mbps 0 retrans
8192.0000 MB / 10.03 sec = 6852.2803 Mbps 13 %TX 32 %RX 33 retrans 80.81 msRTT
And:
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.8241 Mbps 0 retrans
1148.8125 MB / 1.00 sec = 9636.9570 Mbps 0 retrans
1177.3750 MB / 1.00 sec = 9876.4287 Mbps 0 retrans
1177.4375 MB / 1.00 sec = 9877.0024 Mbps 0 retrans
693.5000 MB / 1.00 sec = 5817.6335 Mbps 36 retrans
263.4375 MB / 1.00 sec = 2209.7701 Mbps 0 retrans
1137.3125 MB / 1.00 sec = 9540.7263 Mbps 0 retrans
1169.9375 MB / 1.00 sec = 9814.2354 Mbps 0 retrans
1168.6875 MB / 1.00 sec = 9803.7005 Mbps 0 retrans
8192.0000 MB / 9.21 sec = 7460.8789 Mbps 14 %TX 34 %RX 36 retrans 80.81 msRTT
Re-enabling hystart immediately gives a clean test with no TCP retrans.
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.8075 Mbps 0 retrans
1072.3125 MB / 1.00 sec = 8995.0653 Mbps 0 retrans
1089.4375 MB / 1.00 sec = 9139.0926 Mbps 0 retrans
1093.1875 MB / 1.00 sec = 9170.0646 Mbps 0 retrans
1095.5625 MB / 1.00 sec = 9190.3914 Mbps 0 retrans
1095.5000 MB / 1.00 sec = 9189.8303 Mbps 0 retrans
1097.6875 MB / 1.00 sec = 9207.8952 Mbps 0 retrans
1104.1875 MB / 1.00 sec = 9262.5405 Mbps 0 retrans
8192.0000 MB / 8.48 sec = 8104.4831 Mbps 15 %TX 38 %RX 0 retrans 80.77 msRTT
-Bill
Previous HZ=1000 tests (with tcp_timestamps disabled):
Here are some tests I performed across real networks, where
congestion is generally not an issue, with a 2.6.35 kernel on
the transmit side.
8 GB transfer across an 18 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
517.9375 MB / 1.00 sec = 4344.6096 Mbps 0 retrans
688.4375 MB / 1.00 sec = 5775.1998 Mbps 0 retrans
692.9375 MB / 1.00 sec = 5812.7462 Mbps 0 retrans
698.0625 MB / 1.00 sec = 5855.8078 Mbps 0 retrans
699.8750 MB / 1.00 sec = 5871.0123 Mbps 0 retrans
710.5625 MB / 1.00 sec = 5960.5707 Mbps 0 retrans
728.8125 MB / 1.00 sec = 6113.7652 Mbps 0 retrans
751.3750 MB / 1.00 sec = 6302.9210 Mbps 0 retrans
783.8750 MB / 1.00 sec = 6575.6201 Mbps 0 retrans
825.1875 MB / 1.00 sec = 6921.8145 Mbps 0 retrans
875.4375 MB / 1.00 sec = 7343.9811 Mbps 0 retrans
8192.0000 MB / 11.26 sec = 6102.4718 Mbps 11 %TX 28 %RX 0 retrans 18.92 msRTT
Ramps up quickly to a little under 6 Gbps, then increases more
slowly to 7+ Gbps, with no TCP retransmissions.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and hystart:
i7test7% nuttcp -n8g -w40m -i1 192.168.1.23
970.0625 MB / 1.00 sec = 8136.8475 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9909.0045 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.6369 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.8747 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0531 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.8153 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0729 Mbps 0 retrans
8192.0000 MB / 7.13 sec = 9633.5814 Mbps 17 %TX 42 %RX 0 retrans 18.91 msRTT
Quickly ramps up to full 10-GigE line rate, with no TCP retrans.
8 GB transfer across an 18 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
845.4375 MB / 1.00 sec = 7091.5828 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9910.0134 Mbps 0 retrans
1181.0625 MB / 1.00 sec = 9907.1830 Mbps 0 retrans
1181.4375 MB / 1.00 sec = 9910.8936 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.1721 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.5774 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.6874 Mbps 0 retrans
8192.0000 MB / 7.25 sec = 9484.4524 Mbps 18 %TX 41 %RX 0 retrans 18.92 msRTT
Also quickly ramps up to full 10-GigE line rate, with no TCP retrans.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -w40m -i1 192.168.1.23
969.8750 MB / 1.00 sec = 8135.6571 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.3990 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.9342 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.4098 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.8252 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0630 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.3504 Mbps 0 retrans
8192.0000 MB / 7.15 sec = 9611.8053 Mbps 18 %TX 42 %RX 0 retrans 18.95 msRTT
Basically the same as the case with 40 MB socket buffer and hystart enabled.
Now trying the same type of tests across an 80 ms RTT path.
8 GB transfer across an 80 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
11.3125 MB / 1.00 sec = 94.8954 Mbps 0 retrans
441.5625 MB / 1.00 sec = 3704.1021 Mbps 0 retrans
687.3750 MB / 1.00 sec = 5765.8657 Mbps 0 retrans
715.5625 MB / 1.00 sec = 6002.6273 Mbps 0 retrans
709.9375 MB / 1.00 sec = 5955.5958 Mbps 0 retrans
691.3125 MB / 1.00 sec = 5799.0626 Mbps 0 retrans
718.6250 MB / 1.00 sec = 6028.3538 Mbps 0 retrans
718.0000 MB / 1.00 sec = 6023.0205 Mbps 0 retrans
704.0000 MB / 1.00 sec = 5905.5387 Mbps 0 retrans
733.3125 MB / 1.00 sec = 6151.4096 Mbps 0 retrans
738.8750 MB / 1.00 sec = 6198.2381 Mbps 0 retrans
731.8750 MB / 1.00 sec = 6139.3695 Mbps 0 retrans
8192.0000 MB / 12.85 sec = 5348.9677 Mbps 10 %TX 23 %RX 0 retrans 80.81 msRTT
Similar to the 20 ms RTT path, but achieving somewhat lower
performance levels, presumably due to the larger RTT. Ramps
up fairly quickly to a little under 6 Gbps, then increases
more slowly to 6+ Gbps, with no TCP retransmissions.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and hystart:
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
103.9375 MB / 1.00 sec = 871.8378 Mbps 0 retrans
1086.5625 MB / 1.00 sec = 9114.6102 Mbps 0 retrans
1106.6875 MB / 1.00 sec = 9283.5583 Mbps 0 retrans
1109.3125 MB / 1.00 sec = 9305.5226 Mbps 0 retrans
1111.1875 MB / 1.00 sec = 9321.9596 Mbps 0 retrans
1112.8125 MB / 1.00 sec = 9334.8452 Mbps 0 retrans
1113.6875 MB / 1.00 sec = 9341.6620 Mbps 0 retrans
1120.2500 MB / 1.00 sec = 9398.0054 Mbps 0 retrans
8192.0000 MB / 8.37 sec = 8207.2049 Mbps 16 %TX 38 %RX 0 retrans 80.81 msRTT
Quickly ramps up to 9+ Gbps and then slowly increases further,
with no TCP retrans.
8 GB transfer across an 80 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
11.2500 MB / 1.00 sec = 94.3703 Mbps 0 retrans
519.0625 MB / 1.00 sec = 4354.1596 Mbps 0 retrans
861.2500 MB / 1.00 sec = 7224.7970 Mbps 0 retrans
871.0000 MB / 1.00 sec = 7306.4191 Mbps 0 retrans
860.7500 MB / 1.00 sec = 7220.4438 Mbps 0 retrans
869.0625 MB / 1.00 sec = 7290.3340 Mbps 0 retrans
863.4375 MB / 1.00 sec = 7242.7707 Mbps 0 retrans
860.4375 MB / 1.00 sec = 7218.0606 Mbps 0 retrans
875.5000 MB / 1.00 sec = 7344.3071 Mbps 0 retrans
863.1875 MB / 1.00 sec = 7240.8257 Mbps 0 retrans
8192.0000 MB / 10.98 sec = 6259.4379 Mbps 12 %TX 27 %RX 0 retrans 80.81 msRTT
Ramps up quickly to 7+ Gbps, then appears to stabilize at that
level, with no TCP retransmissions. Performance is somewhat
better than with autotuning enabled, but less than using a
manually set 100 MB socket buffer.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
102.8750 MB / 1.00 sec = 862.9487 Mbps 0 retrans
522.8750 MB / 1.00 sec = 4386.2811 Mbps 414 retrans
881.5625 MB / 1.00 sec = 7394.6534 Mbps 0 retrans
1164.3125 MB / 1.00 sec = 9766.6682 Mbps 0 retrans
1170.5625 MB / 1.00 sec = 9819.7042 Mbps 0 retrans
1166.8125 MB / 1.00 sec = 9788.2067 Mbps 0 retrans
1159.8750 MB / 1.00 sec = 9729.1530 Mbps 0 retrans
811.1250 MB / 1.00 sec = 6804.8017 Mbps 21 retrans
73.2500 MB / 1.00 sec = 614.4674 Mbps 0 retrans
884.6250 MB / 1.00 sec = 7420.2900 Mbps 0 retrans
8192.0000 MB / 10.34 sec = 6647.9394 Mbps 13 %TX 31 %RX 435 retrans 80.81 msRTT
Disabling hystart on a large RTT path does not seem to play nice with
a manually specified socket buffer, resulting in TCP retransmissions
that limit the effective network performance.
This is a repeatable but extremely variable phenomenon.
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
103.7500 MB / 1.00 sec = 870.3015 Mbps 0 retrans
1146.3750 MB / 1.00 sec = 9616.4520 Mbps 0 retrans
1175.9375 MB / 1.00 sec = 9864.6070 Mbps 0 retrans
615.6875 MB / 1.00 sec = 5164.7353 Mbps 21 retrans
139.2500 MB / 1.00 sec = 1168.1253 Mbps 0 retrans
1090.0625 MB / 1.00 sec = 9143.8053 Mbps 0 retrans
1170.4375 MB / 1.00 sec = 9818.6654 Mbps 0 retrans
1174.5625 MB / 1.00 sec = 9852.8754 Mbps 0 retrans
1174.8750 MB / 1.00 sec = 9855.6052 Mbps 0 retrans
8192.0000 MB / 9.42 sec = 7292.9879 Mbps 14 %TX 34 %RX 21 retrans 80.81 msRTT
And:
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
102.8125 MB / 1.00 sec = 862.4227 Mbps 0 retrans
1148.4375 MB / 1.00 sec = 9633.6860 Mbps 0 retrans
1177.4375 MB / 1.00 sec = 9877.3086 Mbps 0 retrans
1168.1250 MB / 1.00 sec = 9798.9133 Mbps 11 retrans
133.1250 MB / 1.00 sec = 1116.7457 Mbps 0 retrans
479.8750 MB / 1.00 sec = 4025.4631 Mbps 0 retrans
1150.6875 MB / 1.00 sec = 9652.4830 Mbps 0 retrans
1177.3125 MB / 1.00 sec = 9876.0624 Mbps 0 retrans
1177.3750 MB / 1.00 sec = 9876.0139 Mbps 0 retrans
320.2500 MB / 1.00 sec = 2686.6452 Mbps 19 retrans
64.9375 MB / 1.00 sec = 544.7363 Mbps 0 retrans
73.6250 MB / 1.00 sec = 617.6113 Mbps 0 retrans
8192.0000 MB / 12.39 sec = 5545.7570 Mbps 12 %TX 26 %RX 30 retrans 80.80 msRTT
Re-enabling hystart immediately gives a clean test with no TCP retrans.
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
103.8750 MB / 1.00 sec = 871.3353 Mbps 0 retrans
1086.7500 MB / 1.00 sec = 9116.4474 Mbps 0 retrans
1105.8125 MB / 1.00 sec = 9276.2276 Mbps 0 retrans
1109.4375 MB / 1.00 sec = 9306.5339 Mbps 0 retrans
1111.3125 MB / 1.00 sec = 9322.5327 Mbps 0 retrans
1111.3750 MB / 1.00 sec = 9322.8053 Mbps 0 retrans
1113.7500 MB / 1.00 sec = 9342.8962 Mbps 0 retrans
1120.3125 MB / 1.00 sec = 9397.5711 Mbps 0 retrans
8192.0000 MB / 8.38 sec = 8204.8394 Mbps 16 %TX 39 %RX 0 retrans 80.80 msRTT
^ permalink raw reply
* Re: [GIT] Networking
From: Steven Rostedt @ 2011-03-11 3:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTimAPqTYT_j6t3cT32WfD6cQPySG0tnQVhC8Z=NO@mail.gmail.com>
On Thu, Mar 10, 2011 at 04:51:34PM -0800, Linus Torvalds wrote:
>
> The reasons can be any of:
>
> - "I don't want to get too far away from upstream". This is very
> understandable, but I have asked people to please _not_ merge "random
> trees of the day". Please use major releases for this (or, if worst
> comes to worst, -rc releases) rather than just do something else.
>
What are you throughts on starting work from a tree. Most of my work is
usually based off of some branch in tip, but sometimes when I'm pulling
in patches that are not really related to anything, I just simply grab
whatever the latest Linus branch is and start from there.
Is it preferable to instead start from one of the official releases?
-- Steve
^ permalink raw reply
* Re: Network performance with small packets
From: Rusty Russell @ 2011-03-10 1:49 UTC (permalink / raw)
To: habanero, Shirley Ma
Cc: Michael S. Tsirkin, Krishna Kumar2, David Miller, kvm, netdev,
steved, Tom Lendacky
In-Reply-To: <1299637278.13202.61.camel@localhost.localdomain>
On Tue, 08 Mar 2011 20:21:18 -0600, Andrew Theurer <habanero@linux.vnet.ibm.com> wrote:
> On Tue, 2011-03-08 at 13:57 -0800, Shirley Ma wrote:
> > On Wed, 2011-02-09 at 11:07 +1030, Rusty Russell wrote:
> > > I've finally read this thread... I think we need to get more serious
> > > with our stats gathering to diagnose these kind of performance issues.
> > >
> > > This is a start; it should tell us what is actually happening to the
> > > virtio ring(s) without significant performance impact...
> >
> > Should we also add similar stat on vhost vq as well for monitoring
> > vhost_signal & vhost_notify?
>
> Tom L has started using Rusty's patches and found some interesting
> results, sent yesterday:
> http://marc.info/?l=kvm&m=129953710930124&w=2
Hmm, I'm not subscribed to kvm@ any more, so I didn't get this, so
replying here:
> Also, it looks like vhost is sending a lot of notifications for
> packets it has received before the guest can get scheduled to disable
> notifications and begin processing the packets resulting in some lock
> contention in the guest (and high interrupt rates).
Yes, this is a virtio design flaw, but one that should be fixable.
We have room at the end of the ring, which we can put a "last_used"
count. Then we can tell if wakeups are redundant, before the guest
updates the flag.
Here's an old patch where I played with implementing this:
virtio: put last_used and last_avail index into ring itself.
Generally, the other end of the virtio ring doesn't need to see where
you're up to in consuming the ring. However, to completely understand
what's going on from the outside, this information must be exposed.
For example, if you want to save and restore a virtio_ring, but you're
not the consumer because the kernel is using it directly.
Fortunately, we have room to expand: the ring is always a whole number
of pages and there's hundreds of bytes of padding after the avail ring
and the used ring, whatever the number of descriptors (which must be a
power of 2).
We add a feature bit so the guest can tell the host that it's writing
out the current value there, if it wants to use that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/virtio/virtio_ring.c | 23 +++++++++++++++--------
include/linux/virtio_ring.h | 12 +++++++++++-
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -71,9 +71,6 @@ struct vring_virtqueue
/* Number we've added since last sync. */
unsigned int num_added;
- /* Last used index we've seen. */
- u16 last_used_idx;
-
/* How to notify other side. FIXME: commonalize hcalls! */
void (*notify)(struct virtqueue *vq);
@@ -278,12 +275,13 @@ static void detach_buf(struct vring_virt
static inline bool more_used(const struct vring_virtqueue *vq)
{
- return vq->last_used_idx != vq->vring.used->idx;
+ return vring_last_used(&vq->vring) != vq->vring.used->idx;
}
static void *vring_get_buf(struct virtqueue *_vq, unsigned int *len)
{
struct vring_virtqueue *vq = to_vvq(_vq);
+ struct vring_used_elem *u;
void *ret;
unsigned int i;
@@ -300,8 +298,11 @@ static void *vring_get_buf(struct virtqu
return NULL;
}
- i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id;
- *len = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].len;
+ u = &vq->vring.used->ring[vring_last_used(&vq->vring) % vq->vring.num];
+ i = u->id;
+ *len = u->len;
+ /* Make sure we don't reload i after doing checks. */
+ rmb();
if (unlikely(i >= vq->vring.num)) {
BAD_RING(vq, "id %u out of range\n", i);
@@ -315,7 +316,8 @@ static void *vring_get_buf(struct virtqu
/* detach_buf clears data, so grab it now. */
ret = vq->data[i];
detach_buf(vq, i);
- vq->last_used_idx++;
+ vring_last_used(&vq->vring)++;
+
END_USE(vq);
return ret;
}
@@ -402,7 +404,6 @@ struct virtqueue *vring_new_virtqueue(un
vq->vq.name = name;
vq->notify = notify;
vq->broken = false;
- vq->last_used_idx = 0;
vq->num_added = 0;
list_add_tail(&vq->vq.list, &vdev->vqs);
#ifdef DEBUG
@@ -413,6 +414,10 @@ struct virtqueue *vring_new_virtqueue(un
vq->indirect = virtio_has_feature(vdev, VIRTIO_RING_F_INDIRECT_DESC);
+ /* We publish indices whether they offer it or not: if not, it's junk
+ * space anyway. But calling this acknowledges the feature. */
+ virtio_has_feature(vdev, VIRTIO_RING_F_PUBLISH_INDICES);
+
/* No callback? Tell other side not to bother us. */
if (!callback)
vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
@@ -443,6 +448,8 @@ void vring_transport_features(struct vir
switch (i) {
case VIRTIO_RING_F_INDIRECT_DESC:
break;
+ case VIRTIO_RING_F_PUBLISH_INDICES:
+ break;
default:
/* We don't understand this bit. */
clear_bit(i, vdev->features);
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -29,6 +29,9 @@
/* We support indirect buffer descriptors */
#define VIRTIO_RING_F_INDIRECT_DESC 28
+/* We publish our last-seen used index at the end of the avail ring. */
+#define VIRTIO_RING_F_PUBLISH_INDICES 29
+
/* Virtio ring descriptors: 16 bytes. These can chain together via "next". */
struct vring_desc
{
@@ -87,6 +90,7 @@ struct vring {
* __u16 avail_flags;
* __u16 avail_idx;
* __u16 available[num];
+ * __u16 last_used_idx;
*
* // Padding to the next align boundary.
* char pad[];
@@ -95,6 +99,7 @@ struct vring {
* __u16 used_flags;
* __u16 used_idx;
* struct vring_used_elem used[num];
+ * __u16 last_avail_idx;
* };
*/
static inline void vring_init(struct vring *vr, unsigned int num, void *p,
@@ -111,9 +116,14 @@ static inline unsigned vring_size(unsign
{
return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num)
+ align - 1) & ~(align - 1))
- + sizeof(__u16) * 2 + sizeof(struct vring_used_elem) * num;
+ + sizeof(__u16) * 2 + sizeof(struct vring_used_elem) * num + 2;
}
+/* We publish the last-seen used index at the end of the available ring, and
+ * vice-versa. These are at the end for backwards compatibility. */
+#define vring_last_used(vr) ((vr)->avail->ring[(vr)->num])
+#define vring_last_avail(vr) (*(__u16 *)&(vr)->used->ring[(vr)->num])
+
#ifdef __KERNEL__
#include <linux/irqreturn.h>
struct virtio_device;
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Lucas Nussbaum @ 2011-03-11 5:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110310152848.7b515511@nehalam>
On 10/03/11 at 15:28 -0800, Stephen Hemminger wrote:
> On Tue, 8 Mar 2011 10:32:15 +0100
> Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
>
> > CUBIC Hystart uses two heuristics to exit slow start earlier, before
> > losses start to occur. Unfortunately, it tends to exit slow start far too
> > early, causing poor performance since convergence to the optimal cwnd is
> > then very slow. This was reported in
> > http://permalink.gmane.org/gmane.linux.network/188169 and
> > https://partner-bugzilla.redhat.com/show_bug.cgi?id=616985
>
> Ignore the RHEL bug. RHEL 5 ships with TCP BIC (not CUBIC) by default.
> There are many research papers which show that BIC is too aggressive,
> and not fair.
According to the bug report, the server is running RHEL6 (with CUBIC and
Hystart), it's the client that is running RHEL5.
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: TX from KVM guest virtio_net to vhost issues
From: Rusty Russell @ 2011-03-11 6:19 UTC (permalink / raw)
To: Shirley Ma, Michael S. Tsirkin
Cc: Tom Lendacky, Krishna Kumar2, David Miller, kvm, netdev, steved
In-Reply-To: <1299707197.25664.173.camel@localhost.localdomain>
On Wed, 09 Mar 2011 13:46:36 -0800, Shirley Ma <mashirle@us.ibm.com> wrote:
> Since we have lots of performance discussions about virtio_net and vhost
> communication. I think it's better to have a common understandings of
> the code first, then we can seek the right directions to improve it. We
> also need to collect more statistics data on both virtio and vhost.
>
> Let's look at TX first: from virtio_net(guest) to vhost(host), send vq
> is shared between guest virtio_net and host vhost, it uses memory
> barriers to sync the changes.
>
> In the start:
>
> Guest virtio_net TX send completion interrupt (for freeing used skbs) is
> disable. Guest virtio_net TX send completion interrupt is enabled only
> when send vq is overrun, guest needs to wait vhost to consume more
> available skbs.
>
> Host vhost notification is enabled in the beginning (for consuming
> available skbs); It is disable whenever the send vq is not empty. Once
> the send vq is empty, the notification is enabled by vhost.
>
> In guest start_xmit(), it first frees used skbs, then send available
> skbs to vhost, ideally guest never enables TX send completion interrupts
> to free used skbs if vhost keeps posting used skbs in send vq.
>
> In vhost handle_tx(), it wakes up by guest whenever the send vq has a
> skb to send, once the send vq is not empty, vhost exits handle_tx()
> without enabling notification. Ideally if guest keeps xmit skbs in send
> vq, the notification is never enabled.
>
> I don't see issues on this implementation.
>
> However, in our TCP_STREAM small message size test, we found that
> somehow guest couldn't see more used skbs to free, which caused
> frequently TX send queue overrun.
So it seems like the guest is outrunning the host?
> In our TCP_RR small message size multiple streams test, we found that
> vhost couldn't see more xmit skbs in send vq, thus it enabled
> notification too often.
And here the host is outrunning the guest?
> What's the possible cause here in xmit? How guest, vhost are being
> scheduled? Whether it's possible, guest virtio_net cooperates with vhost
> for ideal performance: both guest virtio_net and vhost can be in pace
> with send vq without many notifications and exits?
We tend to blame the scheduler for all kinds of things, until we find
the real cause :) Nailing things to different CPUs might help us
determine if it really is scheduler...
But if one side outruns the other, it does a lot of unnecessary work
notifying/interrupting it over and over again before the host/guest gets
a chance to shut notifications/interrupts off. Hence the last_used
publishing patch (Xen does this right, I screwed it up).
Long weekend here, and I'm otherwise committed. But if noone has
cleaned up that patch by early next week, I'll try to do so and see if
we can make a real difference.
Cheers,
Rusty.
^ permalink raw reply
* Re: [GIT] Networking
From: Ingo Molnar @ 2011-03-11 6:36 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Linus Torvalds, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <20110311033406.GA11004@home.goodmis.org>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, Mar 10, 2011 at 04:51:34PM -0800, Linus Torvalds wrote:
> >
> > The reasons can be any of:
> >
> > - "I don't want to get too far away from upstream". This is very
> > understandable, but I have asked people to please _not_ merge "random
> > trees of the day". Please use major releases for this (or, if worst
> > comes to worst, -rc releases) rather than just do something else.
>
> What are you throughts on starting work from a tree. Most of my work is usually
> based off of some branch in tip, but sometimes when I'm pulling in patches that
> are not really related to anything, I just simply grab whatever the latest Linus
> branch is and start from there.
>
> Is it preferable to instead start from one of the official releases?
Yes, for clarity of merge history i'm generally asking all people who send pull
requests to -tip to use official -rc's as bases (or -tip branches), *not* some
random daily -git snapshot. If a -git snapshot has to be merged for a good reason
then please amend the merge commit with the Merge-Reason tag describing the good
reason you had.
Thanks,
Ingo
^ permalink raw reply
* how to utilize multi tx queue to sent packets
From: Jon Zhou @ 2011-03-11 6:52 UTC (permalink / raw)
To: netdev@vger.kernel.org
hi
I am doing some test according to the
website:http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
use packet_mmap tx_ring to send packet.
I modified the sample code "packetmmap.c" to make it send packets have different outer ip.
so that with the help of RSS, I can achieve higher throughput.
but one thing I saw at the tx side, is that all the packets are sent via the same tx_queue,
which is conflict with what I saw at the rx side.
any idea to make it sent packets via different tx_queues? (spread across the tx_queues)
thanks
jon
^ permalink raw reply
* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Jamie Iles @ 2011-03-11 8:54 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311014400.GJ9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 02:44:00AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > +#ifdef CONFIG_ARCH_AT91
> > +#define PCLK_NAME "macb_clk"
> > +#else /* CONFIG_ARCH_AT91 */
> > +#define PCLK_NAME "pclk"
> > +#endif
>
> we need change the clock name and avoid the ifdef
> so this will be generic
>
> nb I work on the switch to clkdev currently for avr32 and at91
This should be gone now. Russell made the suggestion to have a fake clk
for hclk on AT91 so I think I've solved that now. There's an updated
patch in my reply to Russell's message but essentially I'm using
at91_clock_associate() to turn "macb_pclk" into "hclk" and "pclk". Does
this seem reasonable?
Jamie
^ permalink raw reply
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Jamie Iles @ 2011-03-11 8:56 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, Nicolas Ferre, netdev, linux-arm-kernel
In-Reply-To: <20110311014140.GI9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 02:41:40AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:17 Thu 10 Mar , Jamie Iles wrote:
> > On Thu, Mar 10, 2011 at 02:06:04PM +0100, Nicolas Ferre wrote:
> > > On 3/10/2011 11:10 AM, Jamie Iles :
> > > > --- a/drivers/net/macb.c
> > > > +++ b/drivers/net/macb.c
> > > > @@ -18,12 +18,10 @@
> > > > #include <linux/netdevice.h>
> > > > #include <linux/etherdevice.h>
> > > > #include <linux/dma-mapping.h>
> > > > +#include <linux/platform_data/macb.h>
> > > > #include <linux/platform_device.h>
> > > > #include <linux/phy.h>
> > > >
> > > > -#include <mach/board.h>
> > > > -#include <mach/cpu.h>
> > >
> > > I did not bouble check but do we need no more cpu_is_ macros?
> >
> > No, I couldn't see any in there and it builds for all of the AT91
> > targets and all of the AVR32 ones that I tried. I can't see any macros
> > in there that are likely to use cpu_is_* internally either.
>
> keep as we need to remove the #ifdef AT91 to cpu_is
>
> I've patch for this
Is this for the user IO register where the value written is conditional
on both RMII/MII and arch type?
Jamie
^ permalink raw reply
* [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Amit Kumar Salecha @ 2011-03-11 9:50 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1299837003-5616-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
o Allow setting speed and auto negotiation parameters for GbE ports.
o Log an error message to indicate duplex setting is not supported in
the hardware currently.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 6 ++-
drivers/net/netxen/netxen_nic_ctx.c | 15 +++++++
drivers/net/netxen/netxen_nic_ethtool.c | 69 ++++++++++--------------------
3 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index a113805..d7299f1 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -739,7 +739,8 @@ struct netxen_recv_context {
#define NX_CDRP_CMD_READ_PEXQ_PARAMETERS 0x0000001c
#define NX_CDRP_CMD_GET_LIC_CAPABILITIES 0x0000001d
#define NX_CDRP_CMD_READ_MAX_LRO_PER_BOARD 0x0000001e
-#define NX_CDRP_CMD_MAX 0x0000001f
+#define NX_CDRP_CMD_CONFIG_GBE_PORT 0x0000001f
+#define NX_CDRP_CMD_MAX 0x00000020
#define NX_RCODE_SUCCESS 0
#define NX_RCODE_NO_HOST_MEM 1
@@ -1054,6 +1055,7 @@ typedef struct {
#define NX_FW_CAPABILITY_BDG (1 << 8)
#define NX_FW_CAPABILITY_FVLANTX (1 << 9)
#define NX_FW_CAPABILITY_HW_LRO (1 << 10)
+#define NX_FW_CAPABILITY_GBE_LINK_CFG (1 << 11)
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
@@ -1349,6 +1351,8 @@ void netxen_advert_link_change(struct netxen_adapter *adapter, int linkup);
void netxen_pci_camqm_read_2M(struct netxen_adapter *, u64, u64 *);
void netxen_pci_camqm_write_2M(struct netxen_adapter *, u64, u64);
+int nx_fw_cmd_set_gbe_port(struct netxen_adapter *adapter,
+ u32 speed, u32 duplex, u32 autoneg);
int nx_fw_cmd_set_mtu(struct netxen_adapter *adapter, int mtu);
int netxen_nic_change_mtu(struct net_device *netdev, int new_mtu);
int netxen_config_hw_lro(struct netxen_adapter *adapter, int enable);
diff --git a/drivers/net/netxen/netxen_nic_ctx.c b/drivers/net/netxen/netxen_nic_ctx.c
index f7d06cb..f16966a 100644
--- a/drivers/net/netxen/netxen_nic_ctx.c
+++ b/drivers/net/netxen/netxen_nic_ctx.c
@@ -112,6 +112,21 @@ nx_fw_cmd_set_mtu(struct netxen_adapter *adapter, int mtu)
return 0;
}
+int
+nx_fw_cmd_set_gbe_port(struct netxen_adapter *adapter,
+ u32 speed, u32 duplex, u32 autoneg)
+{
+
+ return netxen_issue_cmd(adapter,
+ adapter->ahw.pci_func,
+ NXHAL_VERSION,
+ speed,
+ duplex,
+ autoneg,
+ NX_CDRP_CMD_CONFIG_GBE_PORT);
+
+}
+
static int
nx_fw_cmd_create_rx_ctx(struct netxen_adapter *adapter)
{
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
index 587498e..481f331 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -214,7 +214,6 @@ skip:
check_sfp_module = netif_running(dev) &&
adapter->has_link_events;
} else {
- ecmd->autoneg = AUTONEG_ENABLE;
ecmd->supported |= (SUPPORTED_TP |SUPPORTED_Autoneg);
ecmd->advertising |=
(ADVERTISED_TP | ADVERTISED_Autoneg);
@@ -252,53 +251,31 @@ static int
netxen_nic_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
{
struct netxen_adapter *adapter = netdev_priv(dev);
- __u32 status;
+ int ret;
- /* read which mode */
- if (adapter->ahw.port_type == NETXEN_NIC_GBE) {
- /* autonegotiation */
- if (adapter->phy_write &&
- adapter->phy_write(adapter,
- NETXEN_NIU_GB_MII_MGMT_ADDR_AUTONEG,
- ecmd->autoneg) != 0)
- return -EIO;
- else
- adapter->link_autoneg = ecmd->autoneg;
+ if (adapter->ahw.port_type != NETXEN_NIC_GBE)
+ return -EOPNOTSUPP;
- if (adapter->phy_read &&
- adapter->phy_read(adapter,
- NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
- &status) != 0)
- return -EIO;
+ if (!(adapter->capabilities & NX_FW_CAPABILITY_GBE_LINK_CFG)) {
+ netdev_info(dev, "Firmware upgrade required to "
+ "support this operation\n");
+ return -EOPNOTSUPP;
+ }
- /* speed */
- switch (ecmd->speed) {
- case SPEED_10:
- netxen_set_phy_speed(status, 0);
- break;
- case SPEED_100:
- netxen_set_phy_speed(status, 1);
- break;
- case SPEED_1000:
- netxen_set_phy_speed(status, 2);
- break;
- }
- /* set duplex mode */
- if (ecmd->duplex == DUPLEX_HALF)
- netxen_clear_phy_duplex(status);
- if (ecmd->duplex == DUPLEX_FULL)
- netxen_set_phy_duplex(status);
- if (adapter->phy_write &&
- adapter->phy_write(adapter,
- NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
- *((int *)&status)) != 0)
- return -EIO;
- else {
- adapter->link_speed = ecmd->speed;
- adapter->link_duplex = ecmd->duplex;
- }
- } else
+ ret = nx_fw_cmd_set_gbe_port(adapter, ecmd->speed, ecmd->duplex,
+ ecmd->autoneg);
+ if (ret == NX_RCODE_NOT_SUPPORTED && ecmd->duplex == DUPLEX_HALF) {
+ netdev_info(dev, "Speed and autoneg mode settings supported, "
+ "half duplex mode not supported\n");
return -EOPNOTSUPP;
+ } else if (ret) {
+ netdev_info(dev, "Setting speed, duplex or autoneg failed\n");
+ return -EIO;
+ }
+
+ adapter->link_speed = ecmd->speed;
+ adapter->link_duplex = ecmd->duplex;
+ adapter->link_autoneg = ecmd->autoneg;
if (!netif_running(dev))
return 0;
--
1.6.3.3
^ permalink raw reply related
* [PATCH NEXT 1/2] netxen: Notify firmware of Flex-10 interface down
From: Amit Kumar Salecha @ 2011-03-11 9:50 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1299837003-5616-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Notify firmware when a Flex-10 interface is brought down
so that virtual connect manager can display the correct link status.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 33fac32..83348dc 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1032,6 +1032,9 @@ __netxen_nic_down(struct netxen_adapter *adapter, struct net_device *netdev)
netif_carrier_off(netdev);
netif_tx_disable(netdev);
+ if (adapter->capabilities & NX_FW_CAPABILITY_LINK_NOTIFICATION)
+ netxen_linkevent_request(adapter, 0);
+
if (adapter->stop_port)
adapter->stop_port(adapter);
--
1.6.3.3
^ permalink raw reply related
* [PATCH NEXT 0/2]nexten: bug fixes
From: Amit Kumar Salecha @ 2011-03-11 9:50 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
Hi,
Series of 2 bug fixes. Please apply them on net-next.
Thanks
-Amit
^ permalink raw reply
* Re: [PATCH 3/6] tcp_cubic: fix comparison of jiffies
From: Lucas Nussbaum @ 2011-03-11 9:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, sangtae.ha, rhee, netdev
In-Reply-To: <20110310165328.999266946@vyatta.com>
On 10/03/11 at 08:51 -0800, Stephen Hemminger wrote:
> --- a/net/ipv4/tcp_cubic.c 2011-03-10 08:08:32.867492953 -0800
> +++ b/net/ipv4/tcp_cubic.c 2011-03-10 08:24:39.658201745 -0800
> @@ -342,9 +342,11 @@ static void hystart_update(struct sock *
> u32 curr_jiffies = jiffies;
>
> /* first detection parameter - ack-train detection */
> - if (curr_jiffies - ca->last_jiffies <= msecs_to_jiffies(2)) {
> + if ((s32)(curr_jiffies - ca->last_jiffies) <=
> + msecs_to_jiffies(2)) {
> ca->last_jiffies = curr_jiffies;
> - if (curr_jiffies - ca->round_start >= ca->delay_min>>4)
> + if ((s32) (curr_jiffies - ca->round_start) <=
> + ca->delay_min >> 4)
>=, not <=
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [patch] ariadne: remove redundant NULL check
From: Nicolas Kaiser @ 2011-03-11 9:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, j223yang
In-Reply-To: <20110310.144034.39174581.davem@davemloft.net>
* David Miller <davem@davemloft.net>:
> This is one of those terrible old drivers that have bad coding
> style.
Would you like a cleanup patch for this driver?
Best regards,
Nicolas Kaiser
^ permalink raw reply
* RE: [PATCH net-next-2.6 2/7] be2net: Checksum field valid only for TCP/UDP
From: Padmanabh.Ratnakar @ 2011-03-11 10:04 UTC (permalink / raw)
To: linuxram; +Cc: netdev, davem, Sathya.Perla, subbu.seetharaman
In-Reply-To: <20110311000509.GA28596@ram-laptop>
On Mon, Mar 07, 2011 at 06:38:16PM +0530, Padmanabh Ratnakar wrote:
> L4 checksum field is valid only for TCP/UDP packets in Lancer
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> Signed-off-by: Subramanian Seetharaman <subbu.seetharaman@emulex.com>
> ---
> drivers/net/benet/be_main.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index bf34434..ac7ae21 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -865,14 +865,17 @@ static void be_rx_stats_update(struct be_rx_obj *rxo,
>
> static inline bool csum_passed(struct be_eth_rx_compl *rxcp)
> {
> - u8 l4_cksm, ipv6, ipcksm;
> + u8 l4_cksm, ipv6, ipcksm, tcpf, udpf;
>
> l4_cksm = AMAP_GET_BITS(struct amap_eth_rx_compl, l4_cksm, rxcp);
> ipcksm = AMAP_GET_BITS(struct amap_eth_rx_compl, ipcksm, rxcp);
> ipv6 = AMAP_GET_BITS(struct amap_eth_rx_compl, ip_version, rxcp);
> + tcpf = AMAP_GET_BITS(struct amap_eth_rx_compl, tcpf, rxcp);
> + udpf = AMAP_GET_BITS(struct amap_eth_rx_compl, udpf, rxcp);
>
> - /* Ignore ipcksm for ipv6 pkts */
> - return l4_cksm && (ipcksm || ipv6);
> + /* L4 checksum is not reliable for non TCP/UDP packets.
> + * Also ignore ipcksm for ipv6 pkts */
> + return (tcpf || udpf) && l4_cksm && (ipcksm || ipv6);
> Is it invalid for non-Lancer too ? if not, then should'nt the
> above condition be applied only for lancer?
> RP
There is no need to apply this condition only for Lancer. This check works for BE too.
In BE, for non-tcp/udp packets l4_csum is always 0.
Thanks,
Padmanabh
^ permalink raw reply
* Re: [GIT/PATCH v4] xen network backend driver
From: Ian Campbell @ 2011-03-11 10:22 UTC (permalink / raw)
To: Ben Hutchings
Cc: Stephen Hemminger, netdev@vger.kernel.org, xen-devel,
Jeremy Fitzhardinge, Herbert Xu, Konrad Rzeszutek Wilk,
Francois Romieu
In-Reply-To: <1299778213.2807.11.camel@bwh-desktop>
On Thu, 2011-03-10 at 17:30 +0000, Ben Hutchings wrote:
> On Thu, 2011-03-10 at 09:15 -0800, Stephen Hemminger wrote:
> > On Thu, 10 Mar 2011 17:02:33 +0000
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > +struct xenvif {
> > > + /* Unique identifier for this interface. */
> > ...
> > > + struct net_device_stats stats;
> > > +
> >
> > There is already a stats struct in net_device in current kernel
> > versions, unless there is a compelling reason otherwise
> > please use that.
Will do.
> > Also, you probably want to implement per-cpu and 64 bit
> > stats.
>
> The driver is using a single queue, so I don't see what benefit it would
> get from per-cpu stats. At some point it should become multiqueue and
> then it should store per-queue stats.
Agreed.
> 64-bit stats are definitely preferable, but since they're being
> maintained on the data path this may require some significant work.
> (Ian: see <linux/u64_stats_sync.h> for the canonical way to do this.)
> Given that only a relatively few existing drivers do this (I count 13),
> I'm not sure we can reasonably demand that a new driver does - yet.
Is there an example of a driver which also updates the stats on the
datapath?
If it's ok I'd prefer to defer this change for now though.
Ian.
^ permalink raw reply
* Re: [PATCH 0/6] TCP CUBIC and Hystart
From: Lucas Nussbaum @ 2011-03-11 10:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, sangtae.ha, rhee, netdev
In-Reply-To: <20110310165119.224046957@vyatta.com>
On 10/03/11 at 08:51 -0800, Stephen Hemminger wrote:
> This patch set is my attempt at addressing the problems discovered
> by Lucas Nussbaum.
With those patches applied (and the fix I mentioned separately), it
works much better (still with HZ=250).
When a delayed ack train is detected, slow start ends with cwnd ~= 580
(sometimes a bit lower).
When no delayed ack train is detected, slow start ends with the detection of the
delay increase at cwnd in the [700:1100] range.
performance is still not as good as without hystart, but it is more
acceptable:
nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
94.8125 MB / 1.00 sec = 795.3059 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6325 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6222 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6335 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6354 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6231 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.5883 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6297 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6391 Mbps 0 retrans
1024.0000 MB / 9.29 sec = 924.7155 Mbps 14 %TX 28 %RX 0 retrans 11.39 msRTT
During that run, no ack train was detected, but delay increase was detected when cwnd=1105:
hystart_update: cwnd=1105 ssthresh=1105 fnd=2 hs_det=3 cur_rtt=122 delay_min=90 DELTRE=16
However:
echo 1 > /proc/sys/net/ipv4/route/flush; nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
49.5000 MB / 1.00 sec = 415.2278 Mbps 0 retrans
59.0000 MB / 1.00 sec = 494.9318 Mbps 0 retrans
62.1875 MB / 1.00 sec = 521.6535 Mbps 0 retrans
64.1250 MB / 1.00 sec = 537.9329 Mbps 0 retrans
67.0625 MB / 1.00 sec = 562.5486 Mbps 0 retrans
69.4375 MB / 1.00 sec = 582.4840 Mbps 0 retrans
72.3750 MB / 1.00 sec = 607.1395 Mbps 0 retrans
75.3125 MB / 1.00 sec = 631.7557 Mbps 0 retrans
83.1250 MB / 1.00 sec = 697.2975 Mbps 0 retrans
94.3125 MB / 1.00 sec = 791.1569 Mbps 0 retrans
107.6250 MB / 1.00 sec = 902.8194 Mbps 0 retrans
112.2500 MB / 1.00 sec = 941.6231 Mbps 0 retrans
1024.0000 MB / 12.97 sec = 662.2669 Mbps 10 %TX 20 %RX 0 retrans 11.39 msRTT
[ 3050.712333] found ACK TRAIN: cwnd=493 now=2757023598 ca->last_ack=2757023598 ca->round_start=2757023593 ca->delay_min=90 delay_min>>4=5
[ 3050.726045] hystart_update: cwnd=493 ssthresh=493 fnd=1 hs_det=3 cur_rtt=91 delay_min=90 DELTRE=16
(delayed ack train detected when cwnd=493 => slower convergence)
It seems that the ack train length detection is still a bit too sensitive.
Changing:
if ((s32)(now - ca->round_start) >= ca->delay_min >> 4)
To:
if ((s32)(now - ca->round_start) > ca->delay_min >> 4)
makes things slightly better, but slow start still exits too early. (optimal cwnd=941).
I'm not sure if we can really do something more about that. The detection by
ack train length is inherently more likely to trigger false positives since all
acks are considered, not just a few acks at the beginning of the train. I'm
tempted to suggest to disable the ack train length detection by default, but
then it probably solves problems for other people, and the decrease in
performance is more acceptable now.
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [GIT/PATCH v4] xen network backend driver
From: Ian Campbell @ 2011-03-11 10:30 UTC (permalink / raw)
To: Ben Hutchings
Cc: Stephen Hemminger, netdev@vger.kernel.org, xen-devel,
Jeremy Fitzhardinge, Herbert Xu, Konrad Rzeszutek Wilk,
Francois Romieu
In-Reply-To: <1299777438.2807.0.camel@bwh-desktop>
On Thu, 2011-03-10 at 17:17 +0000, Ben Hutchings wrote:
> On Thu, 2011-03-10 at 09:14 -0800, Stephen Hemminger wrote:
> > On Thu, 10 Mar 2011 17:02:33 +0000
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > + /* Flags that must not be set in dev->features */
> > > + int features_disabled;
> >
> > dev->features is unsigned long, so this mask should be as well.
>
> It's u32 now.
That's in net-next only but I think there's no harm in making it u32 in
my netback branch (which is based on a tree which uses unsigned long).
Then it will be correct when merged.
Alternatively I could pull net-next into my branch but I don't think
that's necessary in this case.
Ian.
^ permalink raw reply
* Re: [PATCH 0/6] TCP CUBIC and Hystart
From: Injong Rhee @ 2011-03-11 10:49 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: Stephen Hemminger, davem, sangtae.ha, netdev
In-Reply-To: <20110311102809.GB15941@xanadu.blop.info>
I think the problem is still in clock resolution (i.e., in use of Hz
250). I will look into the issue some more.
On 3/11/11 5:28 AM, Lucas Nussbaum wrote:
> On 10/03/11 at 08:51 -0800, Stephen Hemminger wrote:
>> This patch set is my attempt at addressing the problems discovered
>> by Lucas Nussbaum.
> With those patches applied (and the fix I mentioned separately), it
> works much better (still with HZ=250).
>
> When a delayed ack train is detected, slow start ends with cwnd ~= 580
> (sometimes a bit lower).
> When no delayed ack train is detected, slow start ends with the detection of the
> delay increase at cwnd in the [700:1100] range.
>
> performance is still not as good as without hystart, but it is more
> acceptable:
>
> nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
> 94.8125 MB / 1.00 sec = 795.3059 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6325 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6222 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6335 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6354 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6231 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.5883 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6297 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6391 Mbps 0 retrans
>
> 1024.0000 MB / 9.29 sec = 924.7155 Mbps 14 %TX 28 %RX 0 retrans 11.39 msRTT
> During that run, no ack train was detected, but delay increase was detected when cwnd=1105:
> hystart_update: cwnd=1105 ssthresh=1105 fnd=2 hs_det=3 cur_rtt=122 delay_min=90 DELTRE=16
>
> However:
> echo 1> /proc/sys/net/ipv4/route/flush; nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
> 49.5000 MB / 1.00 sec = 415.2278 Mbps 0 retrans
> 59.0000 MB / 1.00 sec = 494.9318 Mbps 0 retrans
> 62.1875 MB / 1.00 sec = 521.6535 Mbps 0 retrans
> 64.1250 MB / 1.00 sec = 537.9329 Mbps 0 retrans
> 67.0625 MB / 1.00 sec = 562.5486 Mbps 0 retrans
> 69.4375 MB / 1.00 sec = 582.4840 Mbps 0 retrans
> 72.3750 MB / 1.00 sec = 607.1395 Mbps 0 retrans
> 75.3125 MB / 1.00 sec = 631.7557 Mbps 0 retrans
> 83.1250 MB / 1.00 sec = 697.2975 Mbps 0 retrans
> 94.3125 MB / 1.00 sec = 791.1569 Mbps 0 retrans
> 107.6250 MB / 1.00 sec = 902.8194 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6231 Mbps 0 retrans
>
> 1024.0000 MB / 12.97 sec = 662.2669 Mbps 10 %TX 20 %RX 0 retrans 11.39 msRTT
> [ 3050.712333] found ACK TRAIN: cwnd=493 now=2757023598 ca->last_ack=2757023598 ca->round_start=2757023593 ca->delay_min=90 delay_min>>4=5
> [ 3050.726045] hystart_update: cwnd=493 ssthresh=493 fnd=1 hs_det=3 cur_rtt=91 delay_min=90 DELTRE=16
> (delayed ack train detected when cwnd=493 => slower convergence)
>
> It seems that the ack train length detection is still a bit too sensitive.
> Changing:
> if ((s32)(now - ca->round_start)>= ca->delay_min>> 4)
> To:
> if ((s32)(now - ca->round_start)> ca->delay_min>> 4)
> makes things slightly better, but slow start still exits too early. (optimal cwnd=941).
>
> I'm not sure if we can really do something more about that. The detection by
> ack train length is inherently more likely to trigger false positives since all
> acks are considered, not just a few acks at the beginning of the train. I'm
> tempted to suggest to disable the ack train length detection by default, but
> then it probably solves problems for other people, and the decrease in
> performance is more acceptable now.
^ permalink raw reply
* [net-next-2.6 00/11][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-03-11 11:06 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, bphilips
The following series contains FCoE documentation update, ixgb conversion
to the new VLAN model, several fixes and cleanups for e1000e and
the removal of Tx hang detection in ixgbevf (like recent igbvf patch).
The following are changes since commit 1b7fe59322bef9e7a2c05b64a07a66b875299736:
ipv4: Kill flowi arg to fib_select_multipath()
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Bruce Allan (8):
e1000e: use dev_kfree_skb_irq() instead of dev_kfree_skb()
e1000e: magic number cleanup - ETH_ALEN
e1000e: extend timeout for ethtool link test diagnostic
e1000e: extend EEE LPI timer to prevent dropped link
e1000e: do not toggle LANPHYPC value bit when PHY reset is blocked
e1000e: disable jumbo frames on 82579 when MACsec enabled in EEPROM
e1000e: do not suggest the driver supports Wake-on-ARP
e1000e: bump version number
Emil Tantilov (1):
ixgb: convert to new VLAN model
Lior Levy (1):
ixgbevf: remove Tx hang detection
Yi Zou (1):
net: add proper documentation for previously added net_device_ops for
FCoE
drivers/net/e1000e/defines.h | 1 +
drivers/net/e1000e/ethtool.c | 21 ++++++--------
drivers/net/e1000e/hw.h | 5 +--
drivers/net/e1000e/ich8lan.c | 45 +++++++++++++++++++++++------
drivers/net/e1000e/netdev.c | 6 ++--
drivers/net/ixgb/ixgb.h | 2 +-
drivers/net/ixgb/ixgb_ethtool.c | 39 ++++++++++++++++++++++++++
drivers/net/ixgb/ixgb_main.c | 54 ++++++++----------------------------
drivers/net/ixgbevf/ixgbevf.h | 1 -
drivers/net/ixgbevf/ixgbevf_main.c | 50 ---------------------------------
include/linux/netdevice.h | 36 ++++++++++++++++++++++++
11 files changed, 138 insertions(+), 122 deletions(-)
--
1.7.4
^ permalink raw reply
* [net-next-2.6 01/11] ixgb: convert to new VLAN model
From: Jeff Kirsher @ 2011-03-11 11:06 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, bphilips, Jesse Gross, Jeff Kirsher
In-Reply-To: <1299841590-30676-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Based on a patch from Jesse Gross <jesse@nicira.com>
This switches the ixgb driver to use the new VLAN interfaces.
In doing this, it completes the work begun in
ae54496f9e8d40c89e5668205c181dccfa9ecda1 allowing the use of
hardware VLAN insertion without having a VLAN group configured.
CC: Jesse Gross <jesse@nicira.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgb/ixgb.h | 2 +-
drivers/net/ixgb/ixgb_ethtool.c | 39 ++++++++++++++++++++++++++++
drivers/net/ixgb/ixgb_main.c | 54 ++++++++------------------------------
3 files changed, 52 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
index 521c0c7..8f3df04 100644
--- a/drivers/net/ixgb/ixgb.h
+++ b/drivers/net/ixgb/ixgb.h
@@ -149,7 +149,7 @@ struct ixgb_desc_ring {
struct ixgb_adapter {
struct timer_list watchdog_timer;
- struct vlan_group *vlgrp;
+ unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
u32 bd_number;
u32 rx_buffer_len;
u32 part_num;
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index 43994c1..cc53aa1 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -706,6 +706,43 @@ ixgb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
}
}
+static int ixgb_set_flags(struct net_device *netdev, u32 data)
+{
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
+ bool need_reset;
+ int rc;
+
+ /*
+ * Tx VLAN insertion does not work per HW design when Rx stripping is
+ * disabled. Disable txvlan when rxvlan is turned off, and enable
+ * rxvlan when txvlan is turned on.
+ */
+ if (!(data & ETH_FLAG_RXVLAN) &&
+ (netdev->features & NETIF_F_HW_VLAN_TX))
+ data &= ~ETH_FLAG_TXVLAN;
+ else if (data & ETH_FLAG_TXVLAN)
+ data |= ETH_FLAG_RXVLAN;
+
+ need_reset = (data & ETH_FLAG_RXVLAN) !=
+ (netdev->features & NETIF_F_HW_VLAN_RX);
+
+ rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_RXVLAN |
+ ETH_FLAG_TXVLAN);
+ if (rc)
+ return rc;
+
+ if (need_reset) {
+ if (netif_running(netdev)) {
+ ixgb_down(adapter, true);
+ ixgb_up(adapter);
+ ixgb_set_speed_duplex(netdev);
+ } else
+ ixgb_reset(adapter);
+ }
+
+ return 0;
+}
+
static const struct ethtool_ops ixgb_ethtool_ops = {
.get_settings = ixgb_get_settings,
.set_settings = ixgb_set_settings,
@@ -732,6 +769,8 @@ static const struct ethtool_ops ixgb_ethtool_ops = {
.phys_id = ixgb_phys_id,
.get_sset_count = ixgb_get_sset_count,
.get_ethtool_stats = ixgb_get_ethtool_stats,
+ .get_flags = ethtool_op_get_flags,
+ .set_flags = ixgb_set_flags,
};
void ixgb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 5639ccc..0f681ac 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -100,8 +100,6 @@ static void ixgb_tx_timeout_task(struct work_struct *work);
static void ixgb_vlan_strip_enable(struct ixgb_adapter *adapter);
static void ixgb_vlan_strip_disable(struct ixgb_adapter *adapter);
-static void ixgb_vlan_rx_register(struct net_device *netdev,
- struct vlan_group *grp);
static void ixgb_vlan_rx_add_vid(struct net_device *netdev, u16 vid);
static void ixgb_vlan_rx_kill_vid(struct net_device *netdev, u16 vid);
static void ixgb_restore_vlan(struct ixgb_adapter *adapter);
@@ -336,7 +334,6 @@ static const struct net_device_ops ixgb_netdev_ops = {
.ndo_set_mac_address = ixgb_set_mac,
.ndo_change_mtu = ixgb_change_mtu,
.ndo_tx_timeout = ixgb_tx_timeout,
- .ndo_vlan_rx_register = ixgb_vlan_rx_register,
.ndo_vlan_rx_add_vid = ixgb_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = ixgb_vlan_rx_kill_vid,
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -1508,7 +1505,7 @@ ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
DESC_NEEDED)))
return NETDEV_TX_BUSY;
- if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
+ if (vlan_tx_tag_present(skb)) {
tx_flags |= IXGB_TX_FLAGS_VLAN;
vlan_id = vlan_tx_tag_get(skb);
}
@@ -2049,12 +2046,11 @@ ixgb_clean_rx_irq(struct ixgb_adapter *adapter, int *work_done, int work_to_do)
ixgb_rx_checksum(adapter, rx_desc, skb);
skb->protocol = eth_type_trans(skb, netdev);
- if (adapter->vlgrp && (status & IXGB_RX_DESC_STATUS_VP)) {
- vlan_hwaccel_receive_skb(skb, adapter->vlgrp,
- le16_to_cpu(rx_desc->special));
- } else {
- netif_receive_skb(skb);
- }
+ if (status & IXGB_RX_DESC_STATUS_VP)
+ __vlan_hwaccel_put_tag(skb,
+ le16_to_cpu(rx_desc->special));
+
+ netif_receive_skb(skb);
rxdesc_done:
/* clean up descriptor, might be written over by hw */
@@ -2152,20 +2148,6 @@ map_skb:
}
}
-/**
- * ixgb_vlan_rx_register - enables or disables vlan tagging/stripping.
- *
- * @param netdev network interface device structure
- * @param grp indicates to enable or disable tagging/stripping
- **/
-static void
-ixgb_vlan_rx_register(struct net_device *netdev, struct vlan_group *grp)
-{
- struct ixgb_adapter *adapter = netdev_priv(netdev);
-
- adapter->vlgrp = grp;
-}
-
static void
ixgb_vlan_strip_enable(struct ixgb_adapter *adapter)
{
@@ -2200,6 +2182,7 @@ ixgb_vlan_rx_add_vid(struct net_device *netdev, u16 vid)
vfta = IXGB_READ_REG_ARRAY(&adapter->hw, VFTA, index);
vfta |= (1 << (vid & 0x1F));
ixgb_write_vfta(&adapter->hw, index, vfta);
+ set_bit(vid, adapter->active_vlans);
}
static void
@@ -2208,35 +2191,22 @@ ixgb_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
struct ixgb_adapter *adapter = netdev_priv(netdev);
u32 vfta, index;
- ixgb_irq_disable(adapter);
-
- vlan_group_set_device(adapter->vlgrp, vid, NULL);
-
- /* don't enable interrupts unless we are UP */
- if (adapter->netdev->flags & IFF_UP)
- ixgb_irq_enable(adapter);
-
/* remove VID from filter table */
index = (vid >> 5) & 0x7F;
vfta = IXGB_READ_REG_ARRAY(&adapter->hw, VFTA, index);
vfta &= ~(1 << (vid & 0x1F));
ixgb_write_vfta(&adapter->hw, index, vfta);
+ clear_bit(vid, adapter->active_vlans);
}
static void
ixgb_restore_vlan(struct ixgb_adapter *adapter)
{
- ixgb_vlan_rx_register(adapter->netdev, adapter->vlgrp);
-
- if (adapter->vlgrp) {
- u16 vid;
- for (vid = 0; vid < VLAN_N_VID; vid++) {
- if (!vlan_group_get_device(adapter->vlgrp, vid))
- continue;
- ixgb_vlan_rx_add_vid(adapter->netdev, vid);
- }
- }
+ u16 vid;
+
+ for_each_set_bit(vid, adapter->active_vlans, VLAN_N_VID)
+ ixgb_vlan_rx_add_vid(adapter->netdev, vid);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.7.4
^ permalink raw reply related
* [net-next-2.6 05/11] e1000e: magic number cleanup - ETH_ALEN
From: Jeff Kirsher @ 2011-03-11 11:06 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1299841590-30676-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/hw.h | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index bc0860a..307e1ec 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -812,9 +812,8 @@ struct e1000_nvm_operations {
struct e1000_mac_info {
struct e1000_mac_operations ops;
-
- u8 addr[6];
- u8 perm_addr[6];
+ u8 addr[ETH_ALEN];
+ u8 perm_addr[ETH_ALEN];
enum e1000_mac_type type;
--
1.7.4
^ permalink raw reply related
* [net-next-2.6 02/11] net: add proper documentation for previously added net_device_ops for FCoE
From: Jeff Kirsher @ 2011-03-11 11:06 UTC (permalink / raw)
To: davem; +Cc: Yi Zou, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1299841590-30676-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Yi Zou <yi.zou@intel.com>
Add proper documentation for previously added net_device_ops ops for FCoE.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
include/linux/netdevice.h | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 7a07153..604dbf5 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -777,6 +777,42 @@ struct netdev_tc_txq {
* queues stopped. This allows the netdevice to perform queue management
* safely.
*
+ * Fiber Channel over Ethernet (FCoE) offload functions.
+ * int (*ndo_fcoe_enable)(struct net_device *dev);
+ * Called when the FCoE protocol stack wants to start using LLD for FCoE
+ * so the underlying device can perform whatever needed configuration or
+ * initialization to support acceleration of FCoE traffic.
+ *
+ * int (*ndo_fcoe_disable)(struct net_device *dev);
+ * Called when the FCoE protocol stack wants to stop using LLD for FCoE
+ * so the underlying device can perform whatever needed clean-ups to
+ * stop supporting acceleration of FCoE traffic.
+ *
+ * int (*ndo_fcoe_ddp_setup)(struct net_device *dev, u16 xid,
+ * struct scatterlist *sgl, unsigned int sgc);
+ * Called when the FCoE Initiator wants to initialize an I/O that
+ * is a possible candidate for Direct Data Placement (DDP). The LLD can
+ * perform necessary setup and returns 1 to indicate the device is set up
+ * successfully to perform DDP on this I/O, otherwise this returns 0.
+ *
+ * int (*ndo_fcoe_ddp_done)(struct net_device *dev, u16 xid);
+ * Called when the FCoE Initiator/Target is done with the DDPed I/O as
+ * indicated by the FC exchange id 'xid', so the underlying device can
+ * clean up and reuse resources for later DDP requests.
+ *
+ * int (*ndo_fcoe_ddp_target)(struct net_device *dev, u16 xid,
+ * struct scatterlist *sgl, unsigned int sgc);
+ * Called when the FCoE Target wants to initialize an I/O that
+ * is a possible candidate for Direct Data Placement (DDP). The LLD can
+ * perform necessary setup and returns 1 to indicate the device is set up
+ * successfully to perform DDP on this I/O, otherwise this returns 0.
+ *
+ * int (*ndo_fcoe_get_wwn)(struct net_device *dev, u64 *wwn, int type);
+ * Called when the underlying device wants to override default World Wide
+ * Name (WWN) generation mechanism in FCoE protocol stack to pass its own
+ * World Wide Port Name (WWPN) or World Wide Node Name (WWNN) to the FCoE
+ * protocol stack to use.
+ *
* RFS acceleration.
* int (*ndo_rx_flow_steer)(struct net_device *dev, const struct sk_buff *skb,
* u16 rxq_index, u32 flow_id);
--
1.7.4
^ permalink raw reply related
* [net-next-2.6 03/11] ixgbevf: remove Tx hang detection
From: Jeff Kirsher @ 2011-03-11 11:06 UTC (permalink / raw)
To: davem; +Cc: Lior Levy, netdev, gospo, bphilips, Jeff Kirsher
In-Reply-To: <1299841590-30676-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Lior Levy <lior.levy@intel.com>
Removed Tx hang detection mechanism from ixgbevf.
This mechanism has no affect and can cause false alarm messages in some
cases. Especially when VF Tx rate limit is turned on.
The same mechanism was removed recently from igbvf.
Signed-off-by: Lior Levy <lior.levy@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ixgbevf.h | 1 -
drivers/net/ixgbevf/ixgbevf_main.c | 50 ------------------------------------
2 files changed, 0 insertions(+), 51 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf.h b/drivers/net/ixgbevf/ixgbevf.h
index a63efcb..b703f60 100644
--- a/drivers/net/ixgbevf/ixgbevf.h
+++ b/drivers/net/ixgbevf/ixgbevf.h
@@ -207,7 +207,6 @@ struct ixgbevf_adapter {
u64 hw_tso_ctxt;
u64 hw_tso6_ctxt;
u32 tx_timeout_count;
- bool detect_tx_hung;
/* RX */
struct ixgbevf_ring *rx_ring; /* One per active queue */
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index 8276881..c1fb2c1 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -162,40 +162,6 @@ static void ixgbevf_unmap_and_free_tx_resource(struct ixgbevf_adapter *adapter,
/* tx_buffer_info must be completely set up in the transmit path */
}
-static inline bool ixgbevf_check_tx_hang(struct ixgbevf_adapter *adapter,
- struct ixgbevf_ring *tx_ring,
- unsigned int eop)
-{
- struct ixgbe_hw *hw = &adapter->hw;
- u32 head, tail;
-
- /* Detect a transmit hang in hardware, this serializes the
- * check with the clearing of time_stamp and movement of eop */
- head = readl(hw->hw_addr + tx_ring->head);
- tail = readl(hw->hw_addr + tx_ring->tail);
- adapter->detect_tx_hung = false;
- if ((head != tail) &&
- tx_ring->tx_buffer_info[eop].time_stamp &&
- time_after(jiffies, tx_ring->tx_buffer_info[eop].time_stamp + HZ)) {
- /* detected Tx unit hang */
- printk(KERN_ERR "Detected Tx Unit Hang\n"
- " Tx Queue <%d>\n"
- " TDH, TDT <%x>, <%x>\n"
- " next_to_use <%x>\n"
- " next_to_clean <%x>\n"
- "tx_buffer_info[next_to_clean]\n"
- " time_stamp <%lx>\n"
- " jiffies <%lx>\n",
- tx_ring->queue_index,
- head, tail,
- tx_ring->next_to_use, eop,
- tx_ring->tx_buffer_info[eop].time_stamp, jiffies);
- return true;
- }
-
- return false;
-}
-
#define IXGBE_MAX_TXD_PWR 14
#define IXGBE_MAX_DATA_PER_TXD (1 << IXGBE_MAX_TXD_PWR)
@@ -291,16 +257,6 @@ static bool ixgbevf_clean_tx_irq(struct ixgbevf_adapter *adapter,
#endif
}
- if (adapter->detect_tx_hung) {
- if (ixgbevf_check_tx_hang(adapter, tx_ring, i)) {
- /* schedule immediate reset if we believe we hung */
- printk(KERN_INFO
- "tx hang %d detected, resetting adapter\n",
- adapter->tx_timeout_count + 1);
- ixgbevf_tx_timeout(adapter->netdev);
- }
- }
-
/* re-arm the interrupt */
if ((count >= tx_ring->work_limit) &&
(!test_bit(__IXGBEVF_DOWN, &adapter->state))) {
@@ -2412,9 +2368,6 @@ static void ixgbevf_watchdog_task(struct work_struct *work)
10 : 1);
netif_carrier_on(netdev);
netif_tx_wake_all_queues(netdev);
- } else {
- /* Force detection of hung controller */
- adapter->detect_tx_hung = true;
}
} else {
adapter->link_up = false;
@@ -2429,9 +2382,6 @@ static void ixgbevf_watchdog_task(struct work_struct *work)
ixgbevf_update_stats(adapter);
pf_has_reset:
- /* Force detection of hung controller every watchdog period */
- adapter->detect_tx_hung = true;
-
/* Reset the timer */
if (!test_bit(__IXGBEVF_DOWN, &adapter->state))
mod_timer(&adapter->watchdog_timer,
--
1.7.4
^ permalink raw reply related
* [net-next-2.6 04/11] e1000e: use dev_kfree_skb_irq() instead of dev_kfree_skb()
From: Jeff Kirsher @ 2011-03-11 11:06 UTC (permalink / raw)
To: davem
Cc: Bruce Allan, netdev, gospo, bphilips, Prasanna S. Panchamukhi,
Jeff Kirsher
In-Reply-To: <1299841590-30676-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Based on a report and patch originally submitted by Prasanna Panchamukhi.
Use dev_kfree_skb_irq() in e1000_clean_jumbo_rx_irq() since this latter
function is called only in interrupt context. This avoids "Warning:
kfree_skb on hard IRQ" messages.
Cc: "Prasanna S. Panchamukhi" <prasanna.panchamukhi@riverbed.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 455d5a1..c43cdfe 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1322,7 +1322,7 @@ static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
/* an error means any chain goes out the window
* too */
if (rx_ring->rx_skb_top)
- dev_kfree_skb(rx_ring->rx_skb_top);
+ dev_kfree_skb_irq(rx_ring->rx_skb_top);
rx_ring->rx_skb_top = NULL;
goto next_desc;
}
@@ -1395,7 +1395,7 @@ static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
/* eth type trans needs skb->data to point to something */
if (!pskb_may_pull(skb, ETH_HLEN)) {
e_err("pskb_may_pull failed.\n");
- dev_kfree_skb(skb);
+ dev_kfree_skb_irq(skb);
goto next_desc;
}
--
1.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox