* [patch net-next 0/3] team: couple of patches
From: Jiri Pirko @ 2012-07-11 15:34 UTC (permalink / raw)
To: netdev; +Cc: davem
Jiri Pirko (3):
team: use function team_port_txable() for determing enabled and up
port
team: add broadcast mode
team: make team_port_enabled() and team_port_txable() static inline
drivers/net/team/Kconfig | 13 ++++-
drivers/net/team/Makefile | 1 +
drivers/net/team/team.c | 6 ---
drivers/net/team/team_mode_broadcast.c | 88 +++++++++++++++++++++++++++++++
drivers/net/team/team_mode_roundrobin.c | 6 +--
include/linux/if_team.h | 10 +++-
6 files changed, 113 insertions(+), 11 deletions(-)
create mode 100644 drivers/net/team/team_mode_broadcast.c
--
1.7.10.4
^ permalink raw reply
* Re: [RFC PATCH v2] tcp: TCP Small Queues
From: Eric Dumazet @ 2012-07-11 15:25 UTC (permalink / raw)
To: Ben Greear; +Cc: nanditad, netdev, mattmathis, codel, ncardwell, David Miller
In-Reply-To: <4FFD98EA.1040301@candelatech.com>
On Wed, 2012-07-11 at 08:16 -0700, Ben Greear wrote:
> I haven't read your patch in detail, but I was wondering if this feature
> would cause trouble for applications that are servicing many sockets at once
> and so might take several ms between handling each individual socket.
>
Well, this patch has no impact for such applications. In fact their
send()/write() will return to userland faster than before (for very
large send())
> Or, applications that for other reasons cannot service sockets quite
> as fast. Without this feature, they could poke more data into the
> xmit queues to be handled by the kernel while the app goes about it's
> other user-space work?
>
There is no impact for the applications. They queue their data in socket
write queue, and tcp stack do the work to actually transmit data
and handle ACKS.
Before this patch, this work was triggered by :
- Timers
- Incoming ACKS
We now add a third trigger : TX completion
> Maybe this feature could be enabled/tuned on a per-socket basis?
Well, why not, but I want first to see why it would be needed.
I mean, if a single application _needs_ to send MBytes of tcp data in
Qdisc at once, everything else on the machine is stuck (as today)
So just increase global param.
^ permalink raw reply
* Re: [RFC PATCH v2] tcp: TCP Small Queues
From: Ben Greear @ 2012-07-11 15:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, ycheng, dave.taht, netdev, codel, therbert,
mattmathis, nanditad, ncardwell, andrewmcgr, Rick Jones
In-Reply-To: <1342019518.3265.8116.camel@edumazet-glaptop>
On 07/11/2012 08:11 AM, Eric Dumazet wrote:
> On Tue, 2012-07-10 at 17:13 +0200, Eric Dumazet wrote:
>> This introduce TSQ (TCP Small Queues)
>>
>> TSQ goal is to reduce number of TCP packets in xmit queues (qdisc &
>> device queues), to reduce RTT and cwnd bias, part of the bufferbloat
>> problem.
>>
>> sk->sk_wmem_alloc not allowed to grow above a given limit,
>> allowing no more than ~128KB [1] per tcp socket in qdisc/dev layers at a
>> given time.
>>
>> TSO packets are sized/capped to half the limit, so that we have two
>> TSO packets in flight, allowing better bandwidth use.
>>
>> As a side effect, setting the limit to 40000 automatically reduces the
>> standard gso max limit (65536) to 40000/2 : It can help to reduce
>> latencies of high prio packets, having smaller TSO packets.
>>
>> This means we divert sock_wfree() to a tcp_wfree() handler, to
>> queue/send following frames when skb_orphan() [2] is called for the
>> already queued skbs.
>>
>> Results on my dev machine (tg3 nic) are really impressive, using
>> standard pfifo_fast, and with or without TSO/GSO. Without reduction of
>> nominal bandwidth.
>>
>> I no longer have 3MBytes backlogged in qdisc by a single netperf
>> session, and both side socket autotuning no longer use 4 Mbytes.
>>
>> As skb destructor cannot restart xmit itself ( as qdisc lock might be
>> taken at this point ), we delegate the work to a tasklet. We use one
>> tasklest per cpu for performance reasons.
>>
>>
>>
>> [1] New /proc/sys/net/ipv4/tcp_limit_output_bytes tunable
>> [2] skb_orphan() is usually called at TX completion time,
>> but some drivers call it in their start_xmit() handler.
>> These drivers should at least use BQL, or else a single TCP
>> session can still fill the whole NIC TX ring, since TSQ will
>> have no effect.
>
> I am going to send an official patch (I'll put a v3 tag in it)
>
> I believe I did a full implementation, including the xmit() done
> by the user at release_sock() time, if the tasklet found socket owned by
> the user.
>
> Some bench results about the choice of 128KB being the default value:
>
> 64KB seems the 'good' value on 10Gb links to reach max throughput on my
> lab machines (ixgbe adapters).
>
> Using 128KB is a very conservative value to allow link rate on 20Gbps.
>
> Still, it allows less than 1ms of buffering on a Gbit link, and less
> than 8ms on 100Mbit link (instead of 130ms without Small Queues)
I haven't read your patch in detail, but I was wondering if this feature
would cause trouble for applications that are servicing many sockets at once
and so might take several ms between handling each individual socket.
Or, applications that for other reasons cannot service sockets quite
as fast. Without this feature, they could poke more data into the
xmit queues to be handled by the kernel while the app goes about it's
other user-space work?
Maybe this feature could be enabled/tuned on a per-socket basis?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC PATCH v2] tcp: TCP Small Queues
From: Eric Dumazet @ 2012-07-11 15:11 UTC (permalink / raw)
To: David Miller; +Cc: nanditad, netdev, codel, mattmathis, ncardwell
In-Reply-To: <1341933215.3265.5476.camel@edumazet-glaptop>
On Tue, 2012-07-10 at 17:13 +0200, Eric Dumazet wrote:
> This introduce TSQ (TCP Small Queues)
>
> TSQ goal is to reduce number of TCP packets in xmit queues (qdisc &
> device queues), to reduce RTT and cwnd bias, part of the bufferbloat
> problem.
>
> sk->sk_wmem_alloc not allowed to grow above a given limit,
> allowing no more than ~128KB [1] per tcp socket in qdisc/dev layers at a
> given time.
>
> TSO packets are sized/capped to half the limit, so that we have two
> TSO packets in flight, allowing better bandwidth use.
>
> As a side effect, setting the limit to 40000 automatically reduces the
> standard gso max limit (65536) to 40000/2 : It can help to reduce
> latencies of high prio packets, having smaller TSO packets.
>
> This means we divert sock_wfree() to a tcp_wfree() handler, to
> queue/send following frames when skb_orphan() [2] is called for the
> already queued skbs.
>
> Results on my dev machine (tg3 nic) are really impressive, using
> standard pfifo_fast, and with or without TSO/GSO. Without reduction of
> nominal bandwidth.
>
> I no longer have 3MBytes backlogged in qdisc by a single netperf
> session, and both side socket autotuning no longer use 4 Mbytes.
>
> As skb destructor cannot restart xmit itself ( as qdisc lock might be
> taken at this point ), we delegate the work to a tasklet. We use one
> tasklest per cpu for performance reasons.
>
>
>
> [1] New /proc/sys/net/ipv4/tcp_limit_output_bytes tunable
> [2] skb_orphan() is usually called at TX completion time,
> but some drivers call it in their start_xmit() handler.
> These drivers should at least use BQL, or else a single TCP
> session can still fill the whole NIC TX ring, since TSQ will
> have no effect.
I am going to send an official patch (I'll put a v3 tag in it)
I believe I did a full implementation, including the xmit() done
by the user at release_sock() time, if the tasklet found socket owned by
the user.
Some bench results about the choice of 128KB being the default value:
64KB seems the 'good' value on 10Gb links to reach max throughput on my
lab machines (ixgbe adapters).
Using 128KB is a very conservative value to allow link rate on 20Gbps.
Still, it allows less than 1ms of buffering on a Gbit link, and less
than 8ms on 100Mbit link (instead of 130ms without Small Queues)
Tests using a single TCP flow.
Tests on 10Gbit links :
echo 16384 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 16 tpci_snd_cwnd 79
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
392360 392360 16384 20.00 1389.53 10^6bits/s 0.52 S 4.30 S 0.737 1.014 usec/KB
echo 24576 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 33 tpci_snd_cwnd 86
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
396976 396976 16384 20.00 1483.03 10^6bits/s 0.45 S 4.51 S 0.603 0.997 usec/KB
echo 32768 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 19 tpci_snd_cwnd 100
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
461600 461600 16384 20.00 2039.67 10^6bits/s 0.64 S 5.17 S 0.620 0.830 usec/KB
echo 49152 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 28 tpci_snd_cwnd 207
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
955512 955512 16384 20.00 4448.86 10^6bits/s 1.19 S 11.16 S 0.526 0.822 usec/KB
echo 65536 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 399 tpci_snd_cwnd 488
tcpi_reordering 127 tcpi_total_retrans 75
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
2460328 2460328 16384 20.00 5975.12 10^6bits/s 1.81 S 14.65 S 0.595 0.803 usec/KB
echo 81920 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 24 tpci_snd_cwnd 236
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1144768 1144768 16384 20.00 5190.08 10^6bits/s 1.56 S 12.63 S 0.591 0.798 usec/KB
echo 98304 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 20 tpci_snd_cwnd 644
tcpi_reordering 59 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
2991168 2991168 16384 20.00 5976.00 10^6bits/s 1.60 S 14.61 S 0.526 0.801 usec/KB
echo 114688 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 23 tpci_snd_cwnd 683
tcpi_reordering 59 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
3161960 3161960 16384 20.00 5975.14 10^6bits/s 1.42 S 14.78 S 0.469 0.810 usec/KB
echo 131072 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 23 tpci_snd_cwnd 591
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
2728056 2728056 16384 20.00 5976.16 10^6bits/s 1.71 S 14.62 S 0.562 0.802 usec/KB
echo 147456 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 27 tpci_snd_cwnd 697
tcpi_reordering 64 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
3240432 3240432 16384 20.00 5975.64 10^6bits/s 1.51 S 14.78 S 0.498 0.811 usec/KB
echo 163840 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 18 tpci_snd_cwnd 710
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
3277360 3277360 16384 20.00 5975.56 10^6bits/s 1.59 S 14.79 S 0.525 0.811 usec/KB
echo 180224 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 32 tpci_snd_cwnd 701
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
3235816 3235816 16384 20.00 5976.80 10^6bits/s 1.56 S 14.61 S 0.514 0.801 usec/KB
echo 196608 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 502 tpci_snd_cwnd 690
tcpi_reordering 127 tcpi_total_retrans 37
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
3185040 3185040 16384 20.00 5975.46 10^6bits/s 1.50 S 14.67 S 0.493 0.804 usec/KB
echo 262144 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 16 tpci_snd_cwnd 721
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
3448152 3448152 16384 20.00 5975.49 10^6bits/s 1.57 S 14.78 S 0.516 0.811 usec/KB
echo 524288 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 2000 tcpi_rttvar 750 tcpi_snd_ssthresh 16 tpci_snd_cwnd 927
tcpi_reordering 53 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
4194304 4194304 16384 20.01 5976.61 10^6bits/s 1.63 S 14.56 S 0.538 0.798 usec/KB
echo 1048576 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 2500 tcpi_rttvar 750 tcpi_snd_ssthresh 17 tpci_snd_cwnd 1272
tcpi_reordering 90 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
4194304 4194304 16384 20.01 5975.11 10^6bits/s 1.64 S 14.69 S 0.541 0.805 usec/KB
Tests on Gbit link :
echo 16384 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 30 tpci_snd_cwnd 274
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1264784 1264784 16384 20.01 689.70 10^6bits/s 0.22 S 15.05 S 0.634 7.149 usec/KB
echo 24576 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 43 tpci_snd_cwnd 245
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1130920 1130920 16384 20.01 860.21 10^6bits/s 0.25 S 16.05 S 0.576 6.112 usec/KB
echo 32768 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 36 tpci_snd_cwnd 229
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1057064 1057064 16384 20.01 867.76 10^6bits/s 0.28 S 15.46 S 0.634 5.839 usec/KB
echo 49152 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 32 tpci_snd_cwnd 293
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1352488 1352488 16384 20.01 873.61 10^6bits/s 0.21 S 16.25 S 0.483 6.095 usec/KB
echo 65536 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 48 tpci_snd_cwnd 274
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1264784 1264784 16384 20.01 875.90 10^6bits/s 0.19 S 15.56 S 0.421 5.822 usec/KB
echo 81920 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 18 tpci_snd_cwnd 246
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1135536 1135536 16384 20.01 879.10 10^6bits/s 0.26 S 15.92 S 0.590 5.935 usec/KB
echo 98304 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 20 tpci_snd_cwnd 361
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1666376 1666376 16384 20.02 880.30 10^6bits/s 0.25 S 16.07 S 0.560 5.980 usec/KB
echo 114688 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 41 tpci_snd_cwnd 281
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1297096 1297096 16384 20.01 881.30 10^6bits/s 0.26 S 15.96 S 0.569 5.933 usec/KB
echo 131072 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 30 tpci_snd_cwnd 292
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1347872 1347872 16384 20.01 880.43 10^6bits/s 0.23 S 16.71 S 0.511 6.219 usec/KB
echo 147456 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 2000 tcpi_rttvar 750 tcpi_snd_ssthresh 31 tpci_snd_cwnd 286
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1320176 1320176 16384 20.01 880.57 10^6bits/s 0.24 S 16.62 S 0.534 6.187 usec/KB
echo 163840 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 19 tpci_snd_cwnd 406
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1874096 1874096 16384 20.02 880.23 10^6bits/s 0.25 S 17.08 S 0.550 6.358 usec/KB
echo 180224 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 2000 tcpi_rttvar 750 tcpi_snd_ssthresh 27 tpci_snd_cwnd 304
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1403264 1403264 16384 20.01 880.34 10^6bits/s 0.22 S 16.03 S 0.501 5.965 usec/KB
echo 196608 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 2000 tcpi_rttvar 750 tcpi_snd_ssthresh 42 tpci_snd_cwnd 365
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1684840 1684840 16384 20.02 879.73 10^6bits/s 0.26 S 16.82 S 0.578 6.267 usec/KB
echo 262144 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 2875 tcpi_rttvar 750 tcpi_snd_ssthresh 27 tpci_snd_cwnd 471
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
2174136 2174136 16384 20.01 879.89 10^6bits/s 0.25 S 18.52 S 0.556 6.898 usec/KB
echo 524288 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 205000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 5000 tcpi_rttvar 750 tcpi_snd_ssthresh 42 tpci_snd_cwnd 627
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
2894232 2894232 16384 20.03 879.84 10^6bits/s 0.25 S 17.12 S 0.564 6.374 usec/KB
echo 1048576 >/proc/sys/net/ipv4/tcp_limit_output_bytes
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET
tcpi_rto 209000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600
tcpi_rtt 9875 tcpi_rttvar 750 tcpi_snd_ssthresh 33 tpci_snd_cwnd 950
tcpi_reordering 3 tcpi_total_retrans 0
Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
4194304 4194304 16384 20.03 880.70 10^6bits/s 0.25 S 18.44 S 0.560 6.861 usec/KB
^ permalink raw reply
* Re: [PATCH 4/4] asix: Add a new driver for the AX88172A
From: Christian Riesch @ 2012-07-11 15:10 UTC (permalink / raw)
To: michael
Cc: Ben Hutchings, netdev, Oliver Neukum, Eric Dumazet, Allan Chou,
Mark Lord, Grant Grundler, Ming Lei
In-Reply-To: <CABkLObo5v00QKo-X7hEVbMcXA_QwKFA6HfL-Le5VvU2J5Cs2eg@mail.gmail.com>
Hi again,
On Wed, Jul 11, 2012 at 10:27 AM, Christian Riesch
<christian.riesch@omicron.at> wrote:
> Hi Ben and Michael,
>
> On Mon, Jul 9, 2012 at 12:30 PM, Christian Riesch
> <christian.riesch@omicron.at> wrote:
>> Hi Ben and Michael,
>>
>> On Sun, Jul 8, 2012 at 5:39 PM, Michael Riesch <michael@riesch.at> wrote:
>>> On Fri, 2012-07-06 at 18:37 +0100, Ben Hutchings wrote:
>>>> > + priv->mdio->priv = (void *)dev;
>>>> > + priv->mdio->read = &asix_mdio_bus_read;
>>>> > + priv->mdio->write = &asix_mdio_bus_write;
>>>> > + priv->mdio->name = "Asix MDIO Bus";
>>>> > + snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "asix-%s",
>>>> > + dev_name(dev->net->dev.parent));
>>>> [...]
>>>>
>>>> I think you need to ensure that the bus identifier is unique throughout
>>>> its lifetime, but net devices can be renamed and that could lead to a
>>>> collision. Perhaps you could use the ifindex or the USB device path
>>>
>>> Ben,
>>>
>>> the dev_name function in the code above returns the sysfs filename of
>>> the USB device (e.g. 1-0:1.0).
>>>
>>>> (though that might be too long).
>>>
>>> This may be a problem. The bus identifier may be 17 characters long, so
>>> if we leave the endpoint/configuration part (:1.0) and the prefix away
>>> it should be fine in any "normal" system. However, on a system with a
>>> more-than-9-root-hubs 5-tier 127-devices-each USB infrastructure it
>>> results in collisions. So is this approach acceptable?
>>>
>>> Using the ifindex sounds good to me,
>>>
>>> snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "asix-%d",
>>> dev->net->ifindex);
>>>
>>> works on any system with less than 10^12 network interfaces.
>>
>> Ok, I'll change that to use ifindex.
>
> No, I won't.
> At the time the mdio bus is registered, ifindex is not yet set, so the
> snprintf would always result in "asix-0".
What do you think about
snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "usb-%03d:%03d",
dev->udev->bus->busnum, dev->udev->devnum);
??
This would use the busnum/devnum identifier as reported by lsusb and
would be short enough for an mdio bus name.
Thanks, Christian
^ permalink raw reply
* Re: FW: [patch] net/mlx4_en: dereferencing freed memory
From: Hadar Hen Zion @ 2012-07-11 15:01 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, amirv, Or Gerlitz, Alexander Guller, netdev,
kernel-janitors
In-Reply-To: <EB097B4067A7C64DA511817018705AE595EDE0BE@MTLDAG02.mtl.com>
On 7/11/2012 11:32 AM, Amir Vadai wrote:
>
>
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Wednesday, July 11, 2012 9:34 AM
> To: Yevgeny Petrilin
> Cc: David S. Miller; Amir Vadai; Or Gerlitz; Alexander Guller; netdev@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [patch] net/mlx4_en: dereferencing freed memory
>
> We dereferenced "mclist" after the kfree().
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 94375a8..4ce5ca8 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -503,9 +503,7 @@ static void mlx4_en_do_set_multicast(struct work_struct *work)
> /* remove from list */
> list_del(&mclist->list);
> kfree(mclist);
> - }
> -
> - if (mclist->action == MCLIST_ADD) {
> + } else if (mclist->action == MCLIST_ADD) {
> /* attach the address */
> memcpy(&mc_list[10], mclist->addr, ETH_ALEN);
> /* needed for B0 steering support */
>
Hi Dan,
It's the same in here. This is indeed a bug, thanks for spotting this over,
Please add:
Acked-by: Hadar Hen Zion <hadarh@mellanox.co.il>
Hadar
^ permalink raw reply
* Re: [patch] net/mlx4: off by one in parse_trans_rule()
From: Hadar Hen Zion @ 2012-07-11 14:51 UTC (permalink / raw)
To: Dan Carpenter
Cc: Hadar Hen Zion, David S. Miller, Or Gerlitz, Eugenia Emantayev,
Yevgeny Petrilin, netdev, kernel-janitors
In-Reply-To: <20120711063336.GC11812@elgon.mountain>
On 7/11/2012 9:33 AM, Dan Carpenter wrote:
> This should be ">=" here instead of ">". MLX4_NET_TRANS_RULE_NUM is 6.
> We use "spec->id" as an array offset into the __rule_hw_sz[] and
> __sw_id_hw[] arrays which have 6 elements.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mcg.c b/drivers/net/ethernet/mellanox/mlx4/mcg.c
> index bc62f53..5bac0df 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
> @@ -773,7 +773,7 @@ static int parse_trans_rule(struct mlx4_dev *dev, struct mlx4_spec_list *spec,
> [MLX4_NET_TRANS_RULE_ID_UDP] =
> sizeof(struct mlx4_net_trans_rule_hw_tcp_udp)
> };
> - if (spec->id > MLX4_NET_TRANS_RULE_NUM) {
> + if (spec->id >= MLX4_NET_TRANS_RULE_NUM) {
> mlx4_err(dev, "Invalid network rule id. id = %d\n", spec->id);
> return -EINVAL;
> }
>
Hi Dan,
This is indeed a bug, thanks for spotting this over,
Please add:
Acked-by: Hadar Hen Zion <hadarh@mellanox.co.il>
Hadar
^ permalink raw reply
* Re: [PATCH] tc_util: fix incorrect bare number process in get_rate.
From: Stephen Hemminger @ 2012-07-11 14:51 UTC (permalink / raw)
To: Li Wei; +Cc: netdev
In-Reply-To: <4FFD2A42.9080507@cn.fujitsu.com>
On Wed, 11 Jul 2012 15:24:50 +0800
Li Wei <lw@cn.fujitsu.com> wrote:
>
> As the comment and manpage indicated that the bare number means
> bytes per second, so the division is not needed.
> ---
> tc/tc_util.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tc/tc_util.c b/tc/tc_util.c
> index 926ed08..e8d89c1 100644
> --- a/tc/tc_util.c
> +++ b/tc/tc_util.c
> @@ -153,7 +153,7 @@ int get_rate(unsigned *rate, const char *str)
> return -1;
>
> if (*p == '\0') {
> - *rate = bps / 8.; /* assume bytes/sec */
> + *rate = bps; /* assume bytes/sec */
> return 0;
> }
>
Thanks for finding this. The documentation, code and comment do
all need to be the same!
But changing the code as you propose would break existing usage
by scripts. Instead, the man page and comment need to change
to match the reality of the existing application.
^ permalink raw reply
* pull-request: can-next 2012-07-11
From: Marc Kleine-Budde @ 2012-07-11 14:05 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
Hello David,
the fourth pull request for upcoming v3.6 net-next consist of a series
of can_gw netlink cleanups done by Thomas Graf.
regards, Marc
--
The following changes since commit 061a5c316b6526dbc729049a16243ec27937cc31:
Merge branch 'davem-next.r8169' of git://violet.fr.zoreil.com/romieu/linux (2012-07-09 16:09:47 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git for-davem
for you to fetch changes up to 5d91efa8dd8ced8647798d067f2ac8125194be58:
can: gw: Remove pointless casts (2012-07-10 22:36:17 +0200)
----------------------------------------------------------------
Thomas Graf (4):
can: gw: Don't bump nlmsg_len manually
can: gw: Use nla_policy to validate netlink attributes
can: gw: Properly fill the netlink header when responding to RTM_GETROUTE
can: gw: Remove pointless casts
net/can/gw.c | 90 +++++++++++++++++++++-------------------------------------
1 file changed, 33 insertions(+), 57 deletions(-)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: UDP ordering when using multiple rx queue
From: Jean-Michel Hautbois @ 2012-07-11 13:41 UTC (permalink / raw)
To: Merav Sicron; +Cc: netdev
In-Reply-To: <CAL8zT=jMPCv_Lc7gJYGHRhHZop9aWJfp2w1o_cD0Z8SRdtck7Q@mail.gmail.com>
2012/7/11 Jean-Michel Hautbois <jhautbois@gmail.com>:
> 2012/7/11 Merav Sicron <meravs@broadcom.com>:
>> On Wed, 2012-07-11 at 00:53 -0700, Jean-Michel Hautbois wrote:
>>
>>> Several tests lead to a simple conclusion : when the NIC has only one
>>> RX queue, everything is ok (like be2net for instance), but when it has
>>> more than one RX queue, then I can have "lost packets".
>>> This is the case for bnx2x or mlx4 for instance.
>> >From what you describe I assume that you use different source IP /
>> destination IP in each packet - is this something that you can control?
>> Because with the same IP addresses the traffic will be steered to the
>> same queue.
>
> OK, sorry for not having explained that : the packets are multicast
> with a port for each stream. Sending one stream multicast on a bnx2x
> based NIC can lead to several queues used (two, for what I can see)
> and then, to the problem reported.
>
>>> Here are my questions :
>>> - Is it possible to force a driver to use only one rx queue, even if
>>> it can use more without reloading the driver (and this is feasible
>>> only when a parameter exists for that !) ?
>> You can reduce the number of queues using "ethtool -L ethX combined 1".
>> Note however that it will cause automatic driver unload/load.
>
> OK, thanks for this tip :).
>
> JM
I confirm that using ethtool -L eth1 combined 1 solves my issue.
I can have 3Gbps per sec with 5 multicast on 5 ports without any
"packet loss" (again, for my application) and it uses one RX queue
only (of course :)).
One multicast (one port) but with the default combined=8 splits in two
rx queues...
Unicast traffic seems ok (I used netperf in order to check this assumption).
JM
^ permalink raw reply
* The Items are needed urgently and also in large quantity
From: Kapil Bhardwaj @ 2012-07-11 3:07 UTC (permalink / raw)
To: netdev
Compliments of the day,
My company is interested in a different but a similar design of your product. please confirm to us if your company can make provision for the exact product as shown on the Chinese trading firm page below. You can view the sample pictures by loggin in to the link below with your correct business email to view pictures. Please note that this items are needed urgently and also in large quantity.
http://www.elcivismo.com.ar/img/viewtradeorder.htm
Pls send us quote after preview immediately.
Thanks & Regards,
Kapil Bhardwaj
(MANAGING PARTENER)
M/S Shree Ganesh Tradings
69-A, Vijay Block
Laxmi Nagar
Delhi-110092
Tel.: 0091 11 47603504
Fax.: 0091 11 47603501
^ permalink raw reply
* 3.5-rc6: kernel BUG at kernel/timer.c:711!
From: Dave Jones @ 2012-07-11 13:03 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel
[34323.844970] ------------[ cut here ]------------
[34323.845555] kernel BUG at kernel/timer.c:711!
[34323.846110] invalid opcode: 0000 [#1] PREEMPT SMP
[34323.846657] CPU 6
[34323.846670] Modules linked in:
[34323.853968] ebtables
[34323.866941] xt_cpu
[34323.890355] msdos
[34323.920927] ppp_synctty
[34323.959787] raid6_pq
[34323.964221] raid10 shpchp fakephp aer_inject ptp pps_core target_core_file target_core_iblock target_core_pscsi tcm_loop target_core_mod vga16fb sysimgblt fb_sys_fops syscopyarea vgastate output platform_lcd lcd sysfillrect n_r3964 n_gsm nozomi jsm serio_raw altera_ps2 input_polldev sparse_keymap uinput fuse ipt_ULOG nfnetlink tun binfmt_misc sctp libcrc32c caif_socket caif phonet bluetooth rfkill can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr usb_debug i2c_i801 e1000e nfsd nfs_acl auth_rpcgss lockd sunrpc i915 video i2c_algo_bit drm_kms_helper dr
m i2c_core [last unloaded: scsi_wait_scan]
[34323.997915]
[34323.999802] Pid: 15419, comm: trinity-child6 Not tainted 3.5.0-rc6+ #102
[34324.004383] RIP: 0010:[<ffffffff8107de30>] [<ffffffff8107de30>] mod_timer+0x4a0/0x4c0
[34324.006791] RSP: 0018:ffff88004567be08 EFLAGS: 00010246
[34324.008623] RAX: 0000000000000000 RBX: ffff88010eb916b0 RCX: 000000000000000b
[34324.010443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88004567be10
[34324.012731] RBP: ffff88004567be48 R08: 0000000000000000 R09: 0000000000000000
[34324.014511] R10: 0000000000000001 R11: 0000000000000000 R12: 00000001003f0800
[34324.016552] R13: 00000001003f0b71 R14: ffff880123269600 R15: 00000000ffffff01
[34324.018297] FS: 00007fc0dc317740(0000) GS:ffff880148800000(0000) knlGS:0000000000000000
[34324.020111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[34324.021834] CR2: 00007fc0da305000 CR3: 000000001bad8000 CR4: 00000000001407e0
[34324.023532] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[34324.025221] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[34324.026874] Process trinity-child6 (pid: 15419, threadinfo ffff88004567a000, task ffff88002ee58000)
[34324.028515] Stack:
[34324.030127] ffffffff8154108d 0000000000000b04 ffff88004567be28 ffff88010eb91290
[34324.031914] 0000000000000009 0000000000000004 ffff880123269600 00000000ffffff01
[34324.034029] ffff88004567be68 ffffffff81540d1c ffffffff8154518c ffff88010eb91290
[34324.036201] Call Trace:
[34324.037779] [<ffffffff8154108d>] ? lock_sock_nested+0x8d/0xa0
[34324.039370] [<ffffffff81540d1c>] sk_reset_timer+0x1c/0x30
[34324.040921] [<ffffffff8154518c>] ? sock_setsockopt+0x8c/0x950
[34324.042454] [<ffffffff8159d350>] inet_csk_reset_keepalive_timer+0x20/0x30
[34324.043950] [<ffffffff815b491d>] tcp_set_keepalive+0x3d/0x50
[34324.045483] [<ffffffff81545a13>] sock_setsockopt+0x913/0x950
[34324.046946] [<ffffffff811d5b0a>] ? fget_light+0x3ca/0x500
[34324.048379] [<ffffffff81696b19>] ? sysret_check+0x22/0x5d
[34324.050103] [<ffffffff8153f536>] sys_setsockopt+0xc6/0xe0
[34324.051593] [<ffffffff81696aed>] system_call_fastpath+0x1a/0x1f
[34324.052966] Code: 4d ff ff ff 48 c7 c7 60 10 c3 81 e8 7b 6e 05 00 85 c0 0f 85 b8 fd ff ff eb 93 48 8b 75 08 48 89 df e8 85 f0 ff ff e9 df fb ff ff <0f> 0b 4d 89 f5 e9 ad fc ff ff 66 0f 1f 44 00 00 e8 c6 38 60 00
[34324.057257] RIP [<ffffffff8107de30>] mod_timer+0x4a0/0x4c0
[34324.059070] RSP <ffff88004567be08>
[34324.062014] ---[ end trace fedc8673629f8303 ]---
That's...
BUG_ON(!timer->function);
^ permalink raw reply
* Re: [PATCH v3] net: cgroup: fix access the unallocated memory in netprio cgroup
From: Gao feng @ 2012-07-11 12:51 UTC (permalink / raw)
To: Neil Horman
Cc: eric.dumazet, linux-kernel, netdev, lizefan, tj, davem,
Eric Dumazet
In-Reply-To: <20120711121102.GB26643@hmsreliant.think-freely.org>
于 2012年07月11日 20:11, Neil Horman 写道:
> On Wed, Jul 11, 2012 at 04:30:06PM +0800, Gao feng wrote:
>> there are some out of bound accesses in netprio cgroup.
>>
>> now before accessing the dev->priomap.priomap array,we only check
>> if the dev->priomap exist.and because we don't want to see
>> additional bound checkings in fast path, so we should make sure
>> that dev->priomap is null or array size of dev->priomap.priomap
>> is equal to max_prioidx + 1;
>>
>> and it's not needed to call extend_netdev_tabel in write_priomap,
>> we can only allocate the net device's priomap which we change through
>> net_prio.ifpriomap.
>>
>> this patch add a return value for update_netdev_tables & extend_netdev_table,
>> so when new_priomap is allocated failed,write_priomap will stop to access
>> the priomap,and return -ENOMEM back to the userspace to tell the user
>> what happend.
>>
>> Change From v2:
>> 1. protect extend_netdev_table by RTNL.
>> 2. when extend_netdev_table failed,call dev_put to reduce device's refcount.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> ---
>> net/core/netprio_cgroup.c | 54 ++++++++++++++++++++++++++++++++------------
>> 1 files changed, 39 insertions(+), 15 deletions(-)
>>
> I still think the use of max_priomap in write_priomap is racy (please see my
> previous note).
>
> Neil
Yes, you are right :(
we need a v4 patch.
Thanks!
^ permalink raw reply
* [PATCH net-next] r8169: Remove rtl_ocpdr_cond
From: Hayes Wang @ 2012-07-11 12:31 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
No waiting is needed for mac_ocp_{write / read}. And the bit 31 of
OCPDR would not change, so rtl_udelay_loop_wait_high always return
false. That is, the r8168_mac_ocp_read always retuen ~0.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index c29c5fb..1f27318 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1043,13 +1043,6 @@ static void rtl_w1w0_phy_ocp(struct rtl8169_private *tp, int reg, int p, int m)
r8168_phy_ocp_write(tp, reg, (val | p) & ~m);
}
-DECLARE_RTL_COND(rtl_ocpdr_cond)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- return RTL_R32(OCPDR) & OCPAR_FLAG;
-}
-
static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -1058,8 +1051,6 @@ static void r8168_mac_ocp_write(struct rtl8169_private *tp, u32 reg, u32 data)
return;
RTL_W32(OCPDR, OCPAR_FLAG | (reg << 15) | data);
-
- rtl_udelay_loop_wait_low(tp, &rtl_ocpdr_cond, 25, 10);
}
static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg)
@@ -1071,8 +1062,7 @@ static u16 r8168_mac_ocp_read(struct rtl8169_private *tp, u32 reg)
RTL_W32(OCPDR, reg << 15);
- return rtl_udelay_loop_wait_high(tp, &rtl_ocpdr_cond, 25, 10) ?
- RTL_R32(OCPDR) : ~0;
+ return RTL_R32(OCPDR);
}
#define OCP_STD_PHY_BASE 0xa400
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3] net: cgroup: fix access the unallocated memory in netprio cgroup
From: Neil Horman @ 2012-07-11 12:11 UTC (permalink / raw)
To: Gao feng
Cc: eric.dumazet, linux-kernel, netdev, lizefan, tj, davem,
Eric Dumazet
In-Reply-To: <1341995406-12719-1-git-send-email-gaofeng@cn.fujitsu.com>
On Wed, Jul 11, 2012 at 04:30:06PM +0800, Gao feng wrote:
> there are some out of bound accesses in netprio cgroup.
>
> now before accessing the dev->priomap.priomap array,we only check
> if the dev->priomap exist.and because we don't want to see
> additional bound checkings in fast path, so we should make sure
> that dev->priomap is null or array size of dev->priomap.priomap
> is equal to max_prioidx + 1;
>
> and it's not needed to call extend_netdev_tabel in write_priomap,
> we can only allocate the net device's priomap which we change through
> net_prio.ifpriomap.
>
> this patch add a return value for update_netdev_tables & extend_netdev_table,
> so when new_priomap is allocated failed,write_priomap will stop to access
> the priomap,and return -ENOMEM back to the userspace to tell the user
> what happend.
>
> Change From v2:
> 1. protect extend_netdev_table by RTNL.
> 2. when extend_netdev_table failed,call dev_put to reduce device's refcount.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Eric Dumazet <edumazet@google.com>
> ---
> net/core/netprio_cgroup.c | 54 ++++++++++++++++++++++++++++++++------------
> 1 files changed, 39 insertions(+), 15 deletions(-)
>
I still think the use of max_priomap in write_priomap is racy (please see my
previous note).
Neil
^ permalink raw reply
* [PATCH firmware] rtl_nic: update firmware for RTL8168G
From: Hayes Wang @ 2012-07-11 12:10 UTC (permalink / raw)
To: dwmw2, ben; +Cc: romieu, netdev, linux-kernel, Hayes Wang
In-Reply-To: <1341878937.25597.309.camel@deadeye.wl.decadent.org.uk>
File: rtl_nic/rtl8168g-1.fw
Version: 0.0.2
Change the ocp_base of linux driver to OCP_STD_PHY_BASE after setting
firmware. The firmware would modify the ocp_base, and that results the
driver uses the wrong ocp_base to access standard phy after setting
firmware.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 +-
rtl_nic/rtl8168g-1.fw | Bin 4272 -> 4272 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/WHENCE b/WHENCE
index 1fb7951..f46c842 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1817,7 +1817,7 @@ File: rtl_nic/rtl8106e-1.fw
Version: 0.0.1
File: rtl_nic/rtl8168g-1.fw
-Version: 0.0.1
+Version: 0.0.2
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8168g-1.fw b/rtl_nic/rtl8168g-1.fw
index dace1ea98c66de08107ee0857d8a8680d57d7898..bc03a5d28fd07d99a6cc89aa115d8ef8942629a6 100644
GIT binary patch
delta 78
zcmdm>xIs~u0SJmpax4tZEYfui;|=r-^o$e?%=HZo^$m?cl0c9E#6m0#40#iERoN}A
WOw6oI3^qo33-CB_$u|JyzyJVS1PxdK
delta 78
zcmdm>xIs~u0SJmpax4tZEYfui;|=r-^b8dY%=C>c^$m?cl0c9E#DXjg3}F*>RoTs~
Qj7)%NW2CnL4@eRQ08i5lSO5S3
--
1.7.10.4
^ permalink raw reply related
* [RFC PATCH] tun: don't zeroize sock->file on detach
From: Stanislav Kinsbursky @ 2012-07-11 11:48 UTC (permalink / raw)
To: davem; +Cc: netdev, ruanzhijie, linux-kernel
This is a fix for bug, introduced in 3.4 kernel by commit
1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which, among other things, replaced
simple sock_put() by sk_release_kernel(). Below is sequence, which leads to
oops for non-persistent devices:
tun_chr_close()
tun_detach() <== tun->socket.file = NULL
tun_free_netdev()
sk_release_sock()
sock_release(sock->file == NULL)
iput(SOCK_INODE(sock)) <== dereference on NULL pointer
This patch just removes zeroing of socket's file from __tun_detach().
sock_release() will do this.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
drivers/net/tun.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 987aeef..c1639f3 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -185,7 +185,6 @@ static void __tun_detach(struct tun_struct *tun)
netif_tx_lock_bh(tun->dev);
netif_carrier_off(tun->dev);
tun->tfile = NULL;
- tun->socket.file = NULL;
netif_tx_unlock_bh(tun->dev);
/* Drop read queue */
^ permalink raw reply related
* Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF
From: Or Gerlitz @ 2012-07-11 11:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, roland, netdev, ali, sean.hefty, erezsh
In-Reply-To: <1342002453.3265.7447.camel@edumazet-glaptop>
On 7/11/2012 1:27 PM, Eric Dumazet wrote:
> On Wed, 2012-07-11 at 03:06 -0700, David Miller wrote:
>> We have them on the RX flow too, they are called ingress qdiscs (as
>> opposed to egress qdiscs on the TX side).
>>
>> There is nothing mysterious about them, they've been there for more
>> than 15 years.
>
> Sample script [...]
Hi Eric, thanks for the crash / detailed answer... would you agree to
what I wrote, so we can
use the last twenty bytes of skb->cb[] e.g in a similar manner to the
way struct ipoib_cb works?
Or.
^ permalink raw reply
* Re: UDP ordering when using multiple rx queue
From: Jean-Michel Hautbois @ 2012-07-11 11:13 UTC (permalink / raw)
To: Merav Sicron; +Cc: netdev
In-Reply-To: <1342004939.27284.28.camel@lb-tlvb-meravs.il.broadcom.com>
2012/7/11 Merav Sicron <meravs@broadcom.com>:
> On Wed, 2012-07-11 at 00:53 -0700, Jean-Michel Hautbois wrote:
>
>> Several tests lead to a simple conclusion : when the NIC has only one
>> RX queue, everything is ok (like be2net for instance), but when it has
>> more than one RX queue, then I can have "lost packets".
>> This is the case for bnx2x or mlx4 for instance.
> >From what you describe I assume that you use different source IP /
> destination IP in each packet - is this something that you can control?
> Because with the same IP addresses the traffic will be steered to the
> same queue.
OK, sorry for not having explained that : the packets are multicast
with a port for each stream. Sending one stream multicast on a bnx2x
based NIC can lead to several queues used (two, for what I can see)
and then, to the problem reported.
>> Here are my questions :
>> - Is it possible to force a driver to use only one rx queue, even if
>> it can use more without reloading the driver (and this is feasible
>> only when a parameter exists for that !) ?
> You can reduce the number of queues using "ethtool -L ethX combined 1".
> Note however that it will cause automatic driver unload/load.
OK, thanks for this tip :).
JM
^ permalink raw reply
* Re: UDP ordering when using multiple rx queue
From: Merav Sicron @ 2012-07-11 11:08 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: netdev
In-Reply-To: <CAL8zT=g5nHd6FprhxFc21XTgfXeaokt4QN1fS4ekcNVkuvZE9g@mail.gmail.com>
On Wed, 2012-07-11 at 00:53 -0700, Jean-Michel Hautbois wrote:
> Several tests lead to a simple conclusion : when the NIC has only one
> RX queue, everything is ok (like be2net for instance), but when it has
> more than one RX queue, then I can have "lost packets".
> This is the case for bnx2x or mlx4 for instance.
>From what you describe I assume that you use different source IP /
destination IP in each packet - is this something that you can control?
Because with the same IP addresses the traffic will be steered to the
same queue.
> Here are my questions :
> - Is it possible to force a driver to use only one rx queue, even if
> it can use more without reloading the driver (and this is feasible
> only when a parameter exists for that !) ?
You can reduce the number of queues using "ethtool -L ethX combined 1".
Note however that it will cause automatic driver unload/load.
Thanks,
Merav
^ permalink raw reply
* Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF
From: Eric Dumazet @ 2012-07-11 10:27 UTC (permalink / raw)
To: David Miller; +Cc: ogerlitz, roland, netdev, ali, sean.hefty, erezsh
In-Reply-To: <20120711.030639.1906839917411889365.davem@davemloft.net>
On Wed, 2012-07-11 at 03:06 -0700, David Miller wrote:
> From: Or Gerlitz <ogerlitz@mellanox.com>
> Date: Wed, 11 Jul 2012 12:59:41 +0300
>
> > On 7/11/2012 11:19 AM, David Miller wrote:
> >> handle_ing() goes into the packet scheduler and qdisc layer, the qdisc
> >> layer uses skb->cb[] via struct qdisc_skb_cb
> >
> > Oh, I knew that the qdisc layer touches skb->cb[] but thought it only
> > happens on the TX flow...
>
> We have them on the RX flow too, they are called ingress qdiscs (as
> opposed to egress qdiscs on the TX side).
>
> There is nothing mysterious about them, they've been there for more
> than 15 years.
Sample script
ETH=eth0
IFB=ifb0
LOCALNETS="172.16.0.0/12 192.168.0.0/16 10.0.0.0/8"
RATE="rate 7Mbit bandwidth 7Mbit maxburst 80 minburst 40"
ALLOT="allot 8000"
modprobe ifb
ip link set dev $IFB up
tc qdisc add dev $ETH ingress 2>/dev/null
tc filter add dev $ETH parent ffff: \
protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \
redirect dev $IFB
tc qdisc del dev $IFB root
# Lets say our NIC is 100Mbit
tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \
rate 100Mbit bandwidth 100Mbit
tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \
mpu 64 rate 100Mbit prio 1 \
bandwidth 100Mbit maxburst 150 avpkt 1500 bounded
# Class for traffic coming from Internet : limited to X Mbits
tc class add dev $IFB parent 1:1 classid 1:11 \
cbq $ALLOT mpu 64 \
$RATE prio 2 \
avpkt 1400 bounded
tc qdisc add dev $IFB parent 1:11 handle 11: fq_codel
# Traffic from machines in our LAN : no limit
for privnet in $LOCALNETS
do
tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
match ip src $privnet flowid 1:1
done
tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
match ip protocol 0 0x00 flowid 1:11
^ permalink raw reply
* Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF
From: David Miller @ 2012-07-11 10:06 UTC (permalink / raw)
To: ogerlitz; +Cc: eric.dumazet, roland, netdev, ali, sean.hefty, erezsh
In-Reply-To: <4FFD4E8D.7040608@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 11 Jul 2012 12:59:41 +0300
> On 7/11/2012 11:19 AM, David Miller wrote:
>> handle_ing() goes into the packet scheduler and qdisc layer, the qdisc
>> layer uses skb->cb[] via struct qdisc_skb_cb
>
> Oh, I knew that the qdisc layer touches skb->cb[] but thought it only
> happens on the TX flow...
We have them on the RX flow too, they are called ingress qdiscs (as
opposed to egress qdiscs on the TX side).
There is nothing mysterious about them, they've been there for more
than 15 years.
^ permalink raw reply
* Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF
From: Or Gerlitz @ 2012-07-11 9:59 UTC (permalink / raw)
To: David Miller, eric.dumazet; +Cc: roland, netdev, ali, sean.hefty, erezsh
In-Reply-To: <20120711.011912.2063611962030549397.davem@davemloft.net>
On 7/11/2012 11:19 AM, David Miller wrote:
> handle_ing() goes into the packet scheduler and qdisc layer, the qdisc
> layer uses skb->cb[] via struct qdisc_skb_cb
Oh, I knew that the qdisc layer touches skb->cb[] but thought it only
happens on the TX flow...
Here, the flow Eric pointed on relates to skb which was received by
IPoIB and is soon going
to be consumed by the eIPoIB driver once the rx handler planted by it is
executed on the skb.
So even in this "simple" flow we can't assume that qdisc will not
interfere (why)?
if indeed this is case - I understand that we still can deploy the
practice used by
ipoib_hard_header which uses struct ipoib_cb, or in other words we can
use 20 out
of the 48 bytes of the cb, starting from offset of 28 bytes, correct?
Or.
^ permalink raw reply
* Re: [net-next:master 73/84] net/ipv4/tcp_metrics.c:252:3: error: implicit declaration of function 'inet6_twsk'
From: Fengguang Wu @ 2012-07-11 9:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kernel-janitors
In-Reply-To: <20120711.023939.1269322960321058056.davem@davemloft.net>
On Wed, Jul 11, 2012 at 02:39:39AM -0700, David Miller wrote:
> From: wfg@linux.intel.com
> Date: Wed, 11 Jul 2012 17:12:33 +0800
>
> > net/ipv4/tcp_metrics.c: In function '__tcp_get_metrics_tw':
> > net/ipv4/tcp_metrics.c:252:3: error: implicit declaration of function 'inet6_twsk' [-Werror=implicit-function-declaration]
> > net/ipv4/tcp_metrics.c:252:7: warning: assignment makes pointer from integer without a cast [enabled by default]
> > net/ipv4/tcp_metrics.c:253:41: error: dereferencing pointer to incomplete type
>
> Fixed as follows:
>
> ====================
> ipv6: Move ipv6 twsk accessors outside of CONFIG_IPV6 ifdefs.
>
> Fixes build when ipv6 is disabled.
>
> Reported-by: Fengguang Wu <wfg@linux.intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/linux/ipv6.h | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
It worked, thanks!
Fengguang
^ permalink raw reply
* Re: [net-next:master 73/84] net/ipv4/tcp_metrics.c:252:3: error: implicit declaration of function 'inet6_twsk'
From: David Miller @ 2012-07-11 9:39 UTC (permalink / raw)
To: wfg; +Cc: netdev, kernel-janitors
In-Reply-To: <20120711091233.GA24436@localhost>
From: wfg@linux.intel.com
Date: Wed, 11 Jul 2012 17:12:33 +0800
> net/ipv4/tcp_metrics.c: In function '__tcp_get_metrics_tw':
> net/ipv4/tcp_metrics.c:252:3: error: implicit declaration of function 'inet6_twsk' [-Werror=implicit-function-declaration]
> net/ipv4/tcp_metrics.c:252:7: warning: assignment makes pointer from integer without a cast [enabled by default]
> net/ipv4/tcp_metrics.c:253:41: error: dereferencing pointer to incomplete type
Fixed as follows:
====================
ipv6: Move ipv6 twsk accessors outside of CONFIG_IPV6 ifdefs.
Fixes build when ipv6 is disabled.
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/ipv6.h | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 8260ef7..bc6c8fd 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -410,6 +410,22 @@ struct tcp6_sock {
extern int inet6_sk_rebuild_header(struct sock *sk);
+struct inet6_timewait_sock {
+ struct in6_addr tw_v6_daddr;
+ struct in6_addr tw_v6_rcv_saddr;
+};
+
+struct tcp6_timewait_sock {
+ struct tcp_timewait_sock tcp6tw_tcp;
+ struct inet6_timewait_sock tcp6tw_inet6;
+};
+
+static inline struct inet6_timewait_sock *inet6_twsk(const struct sock *sk)
+{
+ return (struct inet6_timewait_sock *)(((u8 *)sk) +
+ inet_twsk(sk)->tw_ipv6_offset);
+}
+
#if IS_ENABLED(CONFIG_IPV6)
static inline struct ipv6_pinfo * inet6_sk(const struct sock *__sk)
{
@@ -459,28 +475,12 @@ static inline void inet_sk_copy_descendant(struct sock *sk_to,
#define __ipv6_only_sock(sk) (inet6_sk(sk)->ipv6only)
#define ipv6_only_sock(sk) ((sk)->sk_family == PF_INET6 && __ipv6_only_sock(sk))
-struct inet6_timewait_sock {
- struct in6_addr tw_v6_daddr;
- struct in6_addr tw_v6_rcv_saddr;
-};
-
-struct tcp6_timewait_sock {
- struct tcp_timewait_sock tcp6tw_tcp;
- struct inet6_timewait_sock tcp6tw_inet6;
-};
-
static inline u16 inet6_tw_offset(const struct proto *prot)
{
return prot->twsk_prot->twsk_obj_size -
sizeof(struct inet6_timewait_sock);
}
-static inline struct inet6_timewait_sock *inet6_twsk(const struct sock *sk)
-{
- return (struct inet6_timewait_sock *)(((u8 *)sk) +
- inet_twsk(sk)->tw_ipv6_offset);
-}
-
static inline struct in6_addr *__inet6_rcv_saddr(const struct sock *sk)
{
return likely(sk->sk_state != TCP_TIME_WAIT) ?
--
1.7.10.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