* Re: [PATCH v2] sh_eth: Optimization for RX excess judgement
From: Yoshihiro Kaneko @ 2014-12-08 12:16 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, David S. Miller, Simon Horman, Magnus Damm, Linux-sh list
In-Reply-To: <54858FCD.3080206@cogentembedded.com>
Hello Sergei,
2014-12-08 20:47 GMT+09:00 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Hello.
>
> On 12/8/2014 1:48 PM, Yoshihiro Kaneko wrote:
>
>> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
>
>> Both of 'boguscnt' and 'quota' have nearly meaning as the condition of
>> the reception loop.
>> In order to cut down redundant processing, this patch changes excess
>> judgement.
>
>
>> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>> ---
>
>
>> This patch is based on net-next tree.
>
>
>> v2 [Yoshihiro Kaneko]
>> * re-spin for net-next.
>> * remove unneeded check of "quota".
>
>
> This is not a complete list. :-/
Sorry, I'll update on the next time.
>
>> drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
>> b/drivers/net/ethernet/renesas/sh_eth.c
>> index dbe8606..266c9b2 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>
> [...]
>>
>> @@ -1501,6 +1499,8 @@ static int sh_eth_rx(struct net_device *ndev, u32
>> intr_status, int *quota)
>> sh_eth_write(ndev, EDRRR_R, EDRRR);
>> }
>>
>> + *quota -= limit - boguscnt + 1;
>> +
>
>
> Sorry for the wrong previous suggestion, it clearly should have been -1,
> not +1. :-<
Oh, I agree.
Thanks,
Kaneko
>
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH net-next V1] net/mlx4_en: ethtool force speed when asking for autoneg=off
From: Saeed Mahameed @ 2014-12-08 11:42 UTC (permalink / raw)
To: David Laight
Cc: Amir Vadai, David S. Miller, netdev@vger.kernel.org, Or Gerlitz,
Yevgeny Petrilin
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA04B67@AcuExch.aculab.com>
> On Dec 8, 2014, at 12:57 PM, David Laight <David.Laight@ACULAB.COM> wrote:
>
> From: Amir Vadai
>> From: Saeed Mahameed <saeedm@mellanox.com>
>>
>> Use cmd->autoneg == AUTONEG_DISABLE as a user hint to force specific speed.
>> We don't want to rely on ethtool to calculate advertised link modes when
>> forcing specific speed, a user can request a specific speed and specify
>> "autoneg off" in ethtool command to give a hint for forcing this speed.
>
> I'm not 100% sure what you are trying to achieve?
Hey David
I am not trying to fix the operating mode of the phy with this patch.
Here i am trying to give the user the ability To let the driver choose what to advertise when user want to force a specific speed using cmd->autoneg =off .
In the driver :
If (cmd->autoneg==off) advertise_according_speed(cmd->speed)
Else advertise(cmd->advertise)
Thanks
-Saeed
> By far the safest way to 'force' a specific speed is to set the
> advertised modes to contain only the desired speed.
> Doing anything else on links that are capable of auto-negotiation
> is a complete recipe for disaster.
>
> Even if you fix the operating mode of the PHY and MAC you almost
> certainly want to advertise that mode to the remote system.
>
> Yes, I know this is made all the more complicated by 10/100M autodetect.
>
> David
>
>
>
^ permalink raw reply
* Re: [PATCH v2] sh_eth: Optimization for RX excess judgement
From: Sergei Shtylyov @ 2014-12-08 11:47 UTC (permalink / raw)
To: Yoshihiro Kaneko, netdev
Cc: David S. Miller, Simon Horman, Magnus Damm, linux-sh
In-Reply-To: <1418035701-3871-1-git-send-email-ykaneko0929@gmail.com>
Hello.
On 12/8/2014 1:48 PM, Yoshihiro Kaneko wrote:
> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Both of 'boguscnt' and 'quota' have nearly meaning as the condition of
> the reception loop.
> In order to cut down redundant processing, this patch changes excess
> judgement.
> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> ---
> This patch is based on net-next tree.
> v2 [Yoshihiro Kaneko]
> * re-spin for net-next.
> * remove unneeded check of "quota".
This is not a complete list. :-/
> drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index dbe8606..266c9b2 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
> @@ -1501,6 +1499,8 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
> sh_eth_write(ndev, EDRRR_R, EDRRR);
> }
>
> + *quota -= limit - boguscnt + 1;
> +
Sorry for the wrong previous suggestion, it clearly should have been -1,
not +1. :-<
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rocker: remove swdev mode
From: Daniel Borkmann @ 2014-12-08 11:41 UTC (permalink / raw)
To: Jiri Pirko
Cc: Thomas Graf, roopa, sfeldma, jhs, bcrl, john.fastabend, stephen,
linville, vyasevic, netdev, davem, shm, gospo
In-Reply-To: <20141208110301.GA1885@nanopsycho.brq.redhat.com>
On 12/08/2014 12:03 PM, Jiri Pirko wrote:
> Sun, Dec 07, 2014 at 09:19:28AM CET, tgraf@suug.ch wrote:
>> On 12/06/14 at 10:54pm, roopa@cumulusnetworks.com wrote:
>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>
Please provide a normal, non-empty commit message as
everyone else ...
>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
...
>>> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>>> index fded127..9f1d256 100644
>>> --- a/drivers/net/ethernet/rocker/rocker.c
>>> +++ b/drivers/net/ethernet/rocker/rocker.c
>>> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
>>> u32 filter_mask)
>>> {
>>> struct rocker_port *rocker_port = netdev_priv(dev);
>>> - u16 mode = BRIDGE_MODE_SWDEV;
>>> + u16 mode = -1;
>> ^^^
>> I assume you meant s16
>
> well, I see no problem in using u16. IFLA_BRIDGE_MODE attr is u16 so
> mode should stay u16.
>
> But maybe better to add:
> #define BRIDGE_MODE_UNDEF 0xFFFF
Yep, something along these lines seems better.
^ permalink raw reply
* Re: [PATCH net v2 3/5] cxgb4i: handle non-pdu-aligned rx and additional types of negative advice
From: Sergei Shtylyov @ 2014-12-08 11:36 UTC (permalink / raw)
To: kxie, linux-scsi, netdev
Cc: hariprasad, anish, hch, James.Bottomley, michaelc, davem
In-Reply-To: <201412080958.sB89wEsj005499@localhost6.localdomain6>
Hello.
On 12/8/2014 12:58 PM, kxie@chelsio.com wrote:
> [PATCH net v2 3/5] cxgb4i: handle non-pdu-aligned rx data and additional types of negative advice
The patch summary shouldn't be duplicated in the change log, at least not
like this...
> From: Karen Xie <kxie@chelsio.com>
> - abort the connection upon receiving of cpl_rx_data, which means the pdu cannot be recovered from the tcp stream. This could be due to pdu header corruption.
> - handle additional types of negative advice returned by h/w.
> Signed-off-by: Karen Xie <kxie@chelsio.com>
> ---
> drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 34 +++++++++++++++++++++++++++++++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
> diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> index b834bde..051adab 100644
> --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> @@ -845,6 +845,13 @@ static void csk_act_open_retry_timer(unsigned long data)
>
> }
>
> +static inline int is_neg_adv(unsigned int status)
'bool' fits better.
> +{
> + return status == CPL_ERR_RTX_NEG_ADVICE ||
> + status == CPL_ERR_KEEPALV_NEG_ADVICE ||
> + status == CPL_ERR_PERSIST_NEG_ADVICE;
> +}
> +
[...]
> @@ -1027,6 +1033,27 @@ rel_skb:
> __kfree_skb(skb);
> }
>
> +static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
> +{
> + struct cxgbi_sock *csk;
> + struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
> + unsigned int tid = GET_TID(cpl);
> + struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
> + struct tid_info *t = lldi->tids;
> +
> + csk = lookup_tid(t, tid);
> + if (!csk) {
> + pr_err("can't find connection for tid %u.\n", tid);
> + } else {
> + /* not expecting this, reset the connection. */
> + pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
Both situations considered an error?
> + spin_lock_bh(&csk->lock);
> + send_abort_req(csk);
> + spin_unlock_bh(&csk->lock);
> + }
> + __kfree_skb(skb);
> +}
> +
> static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
> {
> struct cxgbi_sock *csk;
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH][net-next] net: avoid to call skb_queue_len again
From: Sergei Shtylyov @ 2014-12-08 11:28 UTC (permalink / raw)
To: Li RongQing, Eric Dumazet; +Cc: netdev
In-Reply-To: <CAJFZqHzeESfMBqb1gQr4DsE-v_fSfUX+AyWbt_VriJJ8Dj2FnA@mail.gmail.com>
Hello.
On 12/8/2014 3:46 AM, Li RongQing wrote:
>>>> From: Li RongQing <roy.qing.li@gmail.com>
>>>> the queue length of sd->input_pkt_queue has been putted into qlen,
>>> s/putted/put/, it's irregular verb.
> I will fix it and resend this patch
>>>> and impossible to change, since hold the lock
>>> I can't parse that. Who holds the lock?
>> This thread/cpu holds the lock to manipulate input_pkt_queue.
>> Otherwise, the following would break horribly....
>> __skb_queue_tail(&sd->input_pkt_queue, skb);
> Thanks Eric
I expect you to also refine the description, so that it's meaningful,
unlike now.
> -Roy
WBR, Sergei
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: Hannes Frederic Sowa @ 2014-12-08 11:25 UTC (permalink / raw)
To: George Spelvin
Cc: davem, dborkman, herbert, linux-kernel, netdev, tgraf, tytso
In-Reply-To: <20141207213354.20910.qmail@ns.horizon.com>
Hi,
On Sun, Dec 7, 2014, at 22:33, George Spelvin wrote:
> On Sun, 2014-12-07 at 15:06 +0100, Hannes Frederic Sowa wrote:
> > In case of openvswitch it shows a performance improvment. The seed
> > parameter could be used as an initial biasing of the crc32 function, but
> > in case of openvswitch it is only set to 0.
>
> NACK.
>
> This is the Fatal Error in thinking that Herbert was warning about.
> The seed parameter doesn't affect CRC32 collisions *at all* if the inputs
> are the same size.
>
> For fixed-size inputs, a non-zero seed is equivalent to XORing a
> constant into the output of the CRC computation.
Sorry for being unclear, I understood that and didn't bother patching
that '0' with a random seed exactly because of this.
> for *different* sized inputs, a non-zero seed detects zero-padding
> better than a zero one, but *which* non-zero value is also irrelevant;
> all-ones is the traditional choice because it's simplest in hardware.
>
>
> A CRC is inherently linear. CRC(a^b) = CRC(a) ^ CRC(b). This makes
> them easy to analyze mathematically and gives them a number of nice
> properties for detecting hardware corruption.
>
> But that same simplicity makes it *ridiculously* easy to generate
> collisions if you try.
Yes, understood and I totally agree we shouldn't use crc32 hashing in a
lot of places where unsafe data is going to be hashed and inserted into
hash tables.
> One way of looking at a CRC is to say that each bit in the input
> has a CRC. The CRC of a message string is just the XOR of the CRCs
> of the individual bits that are set in the message.
>
> Now, a CRC polynomial is chosen so that all of the bits of a
> message have different CRCs. Obviously, there's a limit: when the
> message is 2^n bits long, it's not possible for all the bits to
> have different, non-zero n-bit CRCs.
>
> But a CRC is a really efficient way of assigning different bit patterns
> to different input bits up to that limit.
>
> (Something like CRC32c is also chosen so that, for messages up to a
> reasonable length, no 3-bit, 4-bit, etc. combinations have CRCs that
> XOR to zero.)
>
>
> But, and this might be what Herbert was trying to say and I was
> misunderstanding, if you then *truncate* that CRC, the CRCs of the
> message bits lose that uniqueness guarantee. They're just pseudorandom
> numbers, and a CRC loses its special collision-resistance properties.
>
> It's just an ordinary random hash, and thanks to the birthday paradox,
> you're likely to find two bits whose CRCs agree in any particular 8 bits
> within roughly sqrt(2*256) or 22 bits.
>
> Here are a few such collisions for the least significant 8 bits of
> CRC32c:
>
> Msg1 CRC32c Msg2 CRC32c Match
> 1<<11 3fc5f181 1<<30 bf672381 81
> 1<<12 9d14c3b8 1<<31 dd45aab8 b8
> 1<<5 c79a971f 1<<44 6006181f 1f
> 1<<15 13a29877 1<<45 b2f53777 77
>
> There's nothing special about the lsbits of the CRC.
> Within 64 bits, the most significant 8 bits have it worse:
>
> 1<<5 c79a971f 1<<17 c76580d9 c7
> 1<<6 e13b70f7 1<<18 e144fb14 e1
> 1<<19 70a27d8a 1<<38 7022df58 70
> 1<<20 38513ec5 1<<39 38116fac 38
> 1<<13 4e8a61dc 1<<52 4e2dfd53 4e
> 1<<23 a541927e 1<<53 a5e0c5d1 a5
>
>
> Now, I'd like to stress that this collision rate is no worse than any
> *other* hash function. A truncated CRC loses its special resistance to
> the birthday paradox (you'd have been much smarter to use 8-bit CRC),
> but it doesn't become especially bad. A truncated SHA-1 will have
> coillisions just as often.
>
> The concern with a CRC is that, once you've found one collision, you've
> found a huge number of them. Just XOR the bit pattern of your choice
> into both of the colliding messages, and you have a new collision.
Ack.
> For another example, if you consider the CRC32c of all possible 1-byte
> messages *and then take only the low byte*, there are only 128 possible
> values.
>
> It turns out that the byte 0x5d has a CRC32c of 0xee0d9600. This ends
> in 00, so if I XOR 0x5d into anything, the low 8 bits of the CRC
> don't change.
>
> Likewise, the message "23 00" has a CRC32c of 0x00ee0d96. So you can
> XOR 0x23 into the second-last byte of anything, and the high 8 bits of
> the CRC don't change.
A very interesting read, thanks for your mail!
Bye,
Hannes
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Smart Weblications GmbH - Florian Wiessner @ 2014-12-08 11:19 UTC (permalink / raw)
To: Julian Anastasov
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <alpine.LFD.2.11.1412072019410.1885@ja.home.ssi.bg>
Hi Julian,
Am 07.12.2014 19:27, schrieb Julian Anastasov:>
> Hello,
>
> On Fri, 5 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>> thank you for the fast responses! I would like to test any patch for 3.12.
>
> I'm attaching a patch that avoids rerouting in
> IPVS for LOCAL_IN. Please test it in your setup. My tests
> were with NAT on today's net tree. I checked that it
> compiles for 3.12.33. You can use the default snat_reroute=1.
>
I'm sorry to tell you that your patch does not fix the problem. The BUG happens
as soon as the client sends PASV, the ftp server does not return "Entering
Passive Mode":
[ 91.862502] BUG: unable to handle kernel NULL pointer dereference at
0000000000000014
[ 91.862735] IP: [<ffffffffa013a470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[ 91.862889] PGD 0
[ 91.863026] Oops: 0000 [#1] SMP
[ 91.863235] Modules linked in: netconsole xt_nat xt_multiport ip_vs_rr veth
iptable_mangle xt_mark nf_conntrack_netlink nfnetlink ipt_MASQUERADE iptable_nat
nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter
ip_tables cpufreq_ondemand cpufreq_powersave cpufreq_conservative
cpufreq_userspace ocfs2_stack_o2cb ocfs2_dlm bridge stp llc bonding fuse
nf_conntrack_ftp 8021q openvswitch gre vxlan xt_conntrack x_tables ocfs2_dlmfs
dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue configfs rbd kvm_intel kvm
coretemp ip_vs_ftp ip_vs nf_nat nf_conntrack i2c_i801 psmouse serio_raw lpc_ich
mfd_core evdev btrfs lzo_decompress lzo_compress
[ 91.866846] CPU: 1 PID: 18895 Comm: vsftpd Not tainted 3.12.33 #5
[ 91.866927] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
09/28/2011
[ 91.867023] task: ffff8807b9360540 ti: ffff8807afe90000 task.ti: ffff8807afe90000
[ 91.867116] RIP: 0010:[<ffffffffa013a470>] [<ffffffffa013a470>]
nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[ 91.867268] RSP: 0018:ffff88083fc43988 EFLAGS: 00010206
[ 91.867346] RAX: 000000000000000c RBX: ffff88079aeb006c RCX: 0000000000000003
[ 91.867428] RDX: 000000000000002a RSI: 0000000000000003 RDI: ffff88079aeb006c
[ 91.867509] RBP: 00000000ce63f6dd R08: ffff8807b2eed780 R09: ffff88083fc43998
[ 91.867598] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
[ 91.867679] R13: 0000000000000000 R14: 0000000000000003 R15: ffff880815d948bc
[ 91.867761] FS: 00007f1a8aad5700(0000) GS:ffff88083fc40000(0000)
knlGS:0000000000000000
[ 91.867855] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 91.867926] CR2: 0000000000000014 CR3: 00000007a386a000 CR4: 00000000000407e0
[ 91.868008] Stack:
[ 91.868073] ffff88081690d220 0000000000000012 0000000000000014 ffff88079aeb0068
[ 91.868383] ffff880815d94801 ffffffffa014f681 0000000000000000 ffffffff00000045
[ 91.868694] ffff880800000048 0000001b00000003 ffff88083fc43a60 ffff88081690d220
[ 91.869003] Call Trace:
[ 91.869077] <IRQ>
[ 91.869136] [<ffffffffa014f681>] ? __nf_nat_mangle_tcp_packet+0x109/0x120
[nf_nat]
[ 91.869356] [<ffffffffa017749e>] ? ip_vs_ftp_out.part.8+0x2b2/0x338 [ip_vs_ftp]
[ 91.869460] [<ffffffffa015f884>] ? ip_vs_app_pkt_out+0x105/0x18b [ip_vs]
[ 91.869539] [<ffffffffa0163028>] ? tcp_snat_handler+0x6b/0x320 [ip_vs]
[ 91.869622] [<ffffffffa0155d3d>] ? ip_vs_conn_out_get_proto+0x1c/0x25 [ip_vs]
[ 91.869736] [<ffffffffa015893c>] ? ip_vs_out+0x2a5/0x5f6 [ip_vs]
[ 91.869826] [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[ 91.869906] [<ffffffff81508e1f>] ? nf_iterate+0x42/0x80
[ 91.869996] [<ffffffff81508ec6>] ? nf_hook_slow+0x69/0xff
[ 91.870073] [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[ 91.870153] [<ffffffff8150f8ae>] ? ip_forward+0x22d/0x2cf
[ 91.870230] [<ffffffff814e57ce>] ? __netif_receive_skb_core+0x5f0/0x66c
[ 91.870311] [<ffffffff814e59df>] ? process_backlog+0x13e/0x13e
[ 91.870389] [<ffffffffa0455e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
[ 91.870482] [<ffffffff814e5a2b>] ? netif_receive_skb+0x4c/0x7d
[ 91.870561] [<ffffffffa0455d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
[ 91.870652] [<ffffffffa0455fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
[ 91.870733] [<ffffffff814e567d>] ? __netif_receive_skb_core+0x49f/0x66c
[ 91.870817] [<ffffffff8104daa3>] ? call_timer_fn+0x4b/0xf6
[ 91.870893] [<ffffffff814e592b>] ? process_backlog+0x8a/0x13e
[ 91.870972] [<ffffffff814e5c31>] ? net_rx_action+0xa2/0x1c0
[ 91.871051] [<ffffffff81047e2e>] ? __do_softirq+0xf6/0x24f
[ 91.871132] [<ffffffff815ad7dc>] ? call_softirq+0x1c/0x30
[ 91.871203] <EOI>
[ 91.871260] [<ffffffff8100464d>] ? do_softirq+0x2c/0x5f
[ 91.871470] [<ffffffff81047ca1>] ? local_bh_enable+0x67/0x85
[ 91.871545] [<ffffffff81511689>] ? ip_finish_output+0x2c9/0x322
[ 91.871628] [<ffffffff8151240a>] ? ip_queue_xmit+0x2b7/0x2f0
[ 91.871714] [<ffffffff81524772>] ? tcp_transmit_skb+0x6ef/0x755
[ 91.871792] [<ffffffff815250e8>] ? tcp_write_xmit+0x886/0x9cb
[ 91.871872] [<ffffffff8152527a>] ? __tcp_push_pending_frames+0x24/0x7e
[ 91.871951] [<ffffffff8151a33c>] ? tcp_sendmsg+0xa4c/0xbfc
[ 91.872036] [<ffffffff814d3477>] ? sock_aio_write+0xe3/0xfd
[ 91.872129] [<ffffffff81122f4d>] ? do_sync_write+0x59/0x79
[ 91.872215] [<ffffffff811239e3>] ? vfs_write+0xc4/0x182
[ 91.872298] [<ffffffff81123daf>] ? SyS_write+0x45/0x7c
[ 91.872382] [<ffffffff815ac35b>] ? tracesys+0xdd/0xe2
[ 91.872461] Code: 68 14 4d 01 c5 45 85 e4 74 46 f0 80 4f 78 40 48 8d 5f 04 48
89 df e8 00 12 47 e1 31 c0 41 83 fe 02 0f 97 c0 48 6b c0 0c 4c 01 e8 <8b> 70 08
39 70 04 74 08 89 ea 0f ca 39 10 79 0d 89 70 04 44 01
[ 91.876166] RIP [<ffffffffa013a470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[ 91.876327] RSP <ffff88083fc43988>
[ 91.876400] CR2: 0000000000000014
[ 91.876497] ---[ end trace 2c6d9f405db2170c ]---
[ 91.876578] Kernel panic - not syncing: Fatal exception in interrupt
[ 91.876666] Rebooting in 10 seconds..
[ 101.935360] ACPI MEMORY or I/O RESET_REG.
node01:/ocfs2/usr/src/linux-3.12.33/scripts# ./decodecode
</tmp/node01-kernel-ipvs.log
[ 91.872461] Code: 68 14 4d 01 c5 45 85 e4 74 46 f0 80 4f 78 40 48 8d 5f 04 48
89 df e8 00 12 47 e1 31 c0 41 83 fe 02 0f 97 c0 48 6b c0 0c 4c 01 e8 <8b> 70 08
39 70 04 74 08 89 ea 0f ca 39 10 79 0d 89 70 04 44 01
All code
========
0: 68 14 4d 01 c5 pushq $0xffffffffc5014d14
5: 45 85 e4 test %r12d,%r12d
8: 74 46 je 0x50
a: f0 80 4f 78 40 lock orb $0x40,0x78(%rdi)
f: 48 8d 5f 04 lea 0x4(%rdi),%rbx
13: 48 89 df mov %rbx,%rdi
16: e8 00 12 47 e1 callq 0xffffffffe147121b
1b: 31 c0 xor %eax,%eax
1d: 41 83 fe 02 cmp $0x2,%r14d
21: 0f 97 c0 seta %al
24: 48 6b c0 0c imul $0xc,%rax,%rax
28: 4c 01 e8 add %r13,%rax
2b:* 8b 70 08 mov 0x8(%rax),%esi <-- trapping
instruction
2e: 39 70 04 cmp %esi,0x4(%rax)
31: 74 08 je 0x3b
33: 89 ea mov %ebp,%edx
35: 0f ca bswap %edx
37: 39 10 cmp %edx,(%rax)
39: 79 0d jns 0x48
3b: 89 70 04 mov %esi,0x4(%rax)
3e: 44 rex.R
3f: 01 .byte 0x1
Code starting with the faulting instruction
===========================================
0: 8b 70 08 mov 0x8(%rax),%esi
3: 39 70 04 cmp %esi,0x4(%rax)
6: 74 08 je 0x10
8: 89 ea mov %ebp,%edx
a: 0f ca bswap %edx
c: 39 10 cmp %edx,(%rax)
e: 79 0d jns 0x1d
10: 89 70 04 mov %esi,0x4(%rax)
13: 44 rex.R
14: 01 .byte 0x1
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Jiri Pirko @ 2014-12-08 11:14 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Scott Feldman, Arad, Ronen, Netdev, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <5484B773.7000809@cumulusnetworks.com>
Sun, Dec 07, 2014 at 09:24:19PM CET, roopa@cumulusnetworks.com wrote:
>On 12/5/14, 10:54 PM, Scott Feldman wrote:
>>On Fri, Dec 5, 2014 at 3:21 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
>>>
>>>>-----Original Message-----
>>>>From: netdev-owner@vger.kernel.org [mailto:netdev-
>>>>owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>>>>Sent: Thursday, December 04, 2014 11:02 PM
>>>>To: Scott Feldman
>>>>Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>>>>fastabend; stephen@networkplumber.org; John Linville;
>>>>nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>>>>Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S. Miller;
>>>>shm@cumulusnetworks.com; Andy Gospodarek
>>>>Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>>>>if feature flag set
>>>>
>>>>On 12/4/14, 10:41 PM, Scott Feldman wrote:
>>>>>On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>>>>>>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>>>
>>>>>>This allows offloading to switch asic without having the user to set
>>>>>>any flag. And this is done in the bridge driver to rollback kernel
>>>>>>settings on hw offload failure if required in the future.
>>>>>>
>>>>>>With this, it also makes sure a notification goes out only after the
>>>>>>attributes are set both in the kernel and hw.
>>>>>I like this approach as it streamlines the steps for the user in
>>>>>setting port flags. There is one case for FLOODING where you'll have
>>>>>to turn off flooding for both, and then turn on flooding in hw. You
>>>>>don't want flooding turned on on kernel and hw.
>>>>ok, maybe using the higher bits as in
>>>>https://patchwork.ozlabs.org/patch/413211/
>>>>
>>>>might help with that. Let me think some more.
>>>>>>---
>>>>>> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>>>>>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>>>>>
>>>>>>diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index
>>>>>>9f5eb55..ce173f0 100644
>>>>>>--- a/net/bridge/br_netlink.c
>>>>>>+++ b/net/bridge/br_netlink.c
>>>>>>@@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>>>>nlmsghdr *nlh)
>>>>>> afspec, RTM_SETLINK);
>>>>>> }
>>>>>>
>>>>>>+ if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>>>>>>+ dev->netdev_ops->ndo_bridge_setlink) {
>>>>>>+ int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>>>>>>+ nlh);
>>>>>I think you want to up-level this to net/core/rtnetlink.c because
>>>>>you're only enabling the feature for one instance of a driver that
>>>>>implements ndo_bridge_setlink: the bridge driver. If another driver
>>>>>was MASTER and implemented ndo_bridge_setlink, you'd want same check
>>>>>to push setting down to SELF port driver.
>>>>yeah, i thought about that. But i moved it here so that rollback would be
>>>>easier.
>>>There is a need for propagating setlink/dellink requests down multiple levels.
>>>The use-case I have in mind is a bridge at the top, team/bond in the middle, and port devices at the bottom.
>>>A setlink for VLAN filtering attributes would come with MASTER flag set, and either port or bond/team netdev.
>>>How would this be handled?
>>>
>>>The propagation rules between bridge and enslaved port device could be different from those between bond/team and enslaved devices.
>>>The current bridge driver does not propagate VLAN filtering from bridge to its ports as each port could have different configuration. In a case of a bond/team all members need to have the same configuration such that the a bond/team would be indistinguishable from a simple port.
>>>
>>>Therefore rtnetlink.c might not have the knowledge for propagation across multiple levels.
>>>It seems that each device which implements ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to take care of propagation to its slaves.
>>Thanks Ronen for bringing up this use-case of stacked masters. I
>>think for VLAN filtering, the stacked master case is handled, not by
>>ndo_setlink/dellink at each level, but with ndo_vlan_rx_kill_vid and
>>ndo_vlan_rx_add_vid. So the switch port driver can know VLAN
>>membership for port even if port is under bond which is under bridge,
>>by using ndo_vlan_rx_xxx and setting NETIF_F_HW_VLAN_CTAG_FILTER. The
>>bonding driver's ndo_vlan_rx_xxx handlers seem to keep ports in bond
>>VLAN membership consistent across bond.
>>
>>But in general, ndo_setlink/dellink don't work for the stack use-case
>>for other non-VLAN attributes. Maybe the answer is to use the VLAN
>>propogation model for other attributes. ndo_setlink/dellink/getlink
>>have enough weird-isms it might be time to define cleaner ndo ops to
>>propagate the other attrs down.
>And, only the switch asic driver is interested in these attrs. So, seems like
>for these cases, we need to send these attrs to the switchdriver directly
>instead of going through the stack of netdevs ?. see my response to ronen's
>other email.
I think that this should be handled similar to ndo_vlan_rx_add_vid,
ndo_vlan_rx_kill_vid, ndo_change_mtu and others. Master devices like
bridge, bond, team, etc should take care of propagating the calls to
lower devices. It mignt not make sense sometimes so let the masters to
decide.
I think that the feature bit (ethtool flag) should serve only for user
to actually enable or disable the offload. And thinking about that,
maybe the bit checking should be implemented in switch drivers, not in
bridge and friends.
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize
From: David Vrabel @ 2014-12-08 11:11 UTC (permalink / raw)
To: Luis Henriques, Stefan Bader
Cc: Wei Liu, Ian Campbell, netdev, Kamal Mostafa, linux-kernel,
Paul Durrant, David Vrabel, Zoltan Kiss, xen-devel,
Boris Ostrovsky
In-Reply-To: <20141208101936.GA7491@hercules>
On 08/12/14 10:19, Luis Henriques wrote:
> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>> There is a long known problem with the netfront/netback interface: if the guest
>>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
>>> it gets dropped. The reason is that netback maps these slots to a frag in the
>>> frags array, which is limited by size. Having so many slots can occur since
>>> compound pages were introduced, as the ring protocol slice them up into
>>> individual (non-compound) page aligned slots. The theoretical worst case
>>> scenario looks like this (note, skbs are limited to 64 Kb here):
>>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
>>> using 2 slots
>>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
>>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
>>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
>>> Although I don't think this 51 slots skb can really happen, we need a solution
>>> which can deal with every scenario. In real life there is only a few slots
>>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
>>> most likely have the same buffer layout.
>>> This patch solves this problem by linearizing the packet. This is not the
>>> fastest way, and it can fail much easier as it tries to allocate a big linear
>>> area for the whole packet, but probably easier by an order of magnitude than
>>> anything else. Probably this code path is not touched very frequently anyway.
>>>
>>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
>>> Cc: Wei Liu <wei.liu2@citrix.com>
>>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>>> Cc: Paul Durrant <paul.durrant@citrix.com>
>>> Cc: netdev@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: xen-devel@lists.xenproject.org
>>
>> This does not seem to be marked explicitly as stable. Has someone already asked
>> David Miller to put it on his stable queue? IMO it qualifies quite well and the
>> actual change should be simple to pick/backport.
>>
>
> Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
Don't backport this yes. It's broken. It produces malformed requests
and netback will report a fatal error and stop all traffic on the VIF.
David
^ permalink raw reply
* Re: [PATCH v3 iproute2] bridge link: add option 'self'
From: Jiri Pirko @ 2014-12-08 11:06 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1417854061-4675-1-git-send-email-roopa@cumulusnetworks.com>
Sat, Dec 06, 2014 at 09:21:01AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>Currently self is set internally only if hwmode is set.
>This makes it necessary for the hw to have a mode.
>There is no hwmode really required to go to hardware. So, introduce
>self for anybody who wants to target hardware.
>
>v1 -> v2
> - fix a few bugs. Initialize flags to zero: this was required to
> keep the current behaviour unchanged.
>
>v2 -> v3
> - fix comment
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Jiri Pirko <jiri@resnulli.us>
^ permalink raw reply
* Re: [PATCH net-next v4 0/2] remove bridge BRIDGE_MODE_SWDEV
From: Jiri Pirko @ 2014-12-08 11:04 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1417972147-62196-1-git-send-email-roopa@cumulusnetworks.com>
Please send the patches in reverse order. That would prevent compile
error during bisections. Thanks.
Sun, Dec 07, 2014 at 06:09:04PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>
>Roopa Prabhu (2):
> bridge: remove mode 'swdev'
> rocker: remove swdev mode
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> include/linux/rtnetlink.h | 2 +-
> include/uapi/linux/if_bridge.h | 1 -
> net/core/rtnetlink.c | 12 +++++++++---
> 4 files changed, 11 insertions(+), 22 deletions(-)
>
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rocker: remove swdev mode
From: Jiri Pirko @ 2014-12-08 11:03 UTC (permalink / raw)
To: Thomas Graf
Cc: roopa, sfeldma, jhs, bcrl, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <20141207081928.GA2215@casper.infradead.org>
Sun, Dec 07, 2014 at 09:19:28AM CET, tgraf@suug.ch wrote:
>On 12/06/14 at 10:54pm, roopa@cumulusnetworks.com wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
>> include/linux/rtnetlink.h | 2 +-
>> net/core/rtnetlink.c | 12 +++++++++---
>> 3 files changed, 11 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>> index fded127..9f1d256 100644
>> --- a/drivers/net/ethernet/rocker/rocker.c
>> +++ b/drivers/net/ethernet/rocker/rocker.c
>> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
>> u32 filter_mask)
>> {
>> struct rocker_port *rocker_port = netdev_priv(dev);
>> - u16 mode = BRIDGE_MODE_SWDEV;
>> + u16 mode = -1;
> ^^^
>
>I assume you meant s16
well, I see no problem in using u16. IFLA_BRIDGE_MODE attr is u16 so
mode should stay u16.
But maybe better to add:
#define BRIDGE_MODE_UNDEF 0xFFFF
?
>
^ permalink raw reply
* RE: [PATCH net-next V1] net/mlx4_en: ethtool force speed when asking for autoneg=off
From: David Laight @ 2014-12-08 10:56 UTC (permalink / raw)
To: 'Amir Vadai', David S. Miller
Cc: netdev@vger.kernel.org, Or Gerlitz, Yevgeny Petrilin,
Saeed Mahameed
In-Reply-To: <1417969655-28028-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai
> From: Saeed Mahameed <saeedm@mellanox.com>
>
> Use cmd->autoneg == AUTONEG_DISABLE as a user hint to force specific speed.
> We don't want to rely on ethtool to calculate advertised link modes when
> forcing specific speed, a user can request a specific speed and specify
> "autoneg off" in ethtool command to give a hint for forcing this speed.
I'm not 100% sure what you are trying to achieve?
By far the safest way to 'force' a specific speed is to set the
advertised modes to contain only the desired speed.
Doing anything else on links that are capable of auto-negotiation
is a complete recipe for disaster.
Even if you fix the operating mode of the PHY and MAC you almost
certainly want to advertise that mode to the remote system.
Yes, I know this is made all the more complicated by 10/100M autodetect.
David
^ permalink raw reply
* Update Your Account!!
From: Webmail Administrator @ 2014-12-08 10:42 UTC (permalink / raw)
Dear users Webmail
The answering machine has exceeded the specified storage limit, the system administrator, you may not be able to send or receive new messages until you re-impose revalidate mailbox.To your mailbox
To ensure that you will not experience service interruption, will confirm your account by filling out the credentials of
as follows:
* Username:
* Password:
* Date of birth:
* Country:
System Administrator
Forums Copyright © 2005-2014 VMware, Inc.
VMware and Zimbra are registered trademarks or trademarks of VMware, Inc.
^ permalink raw reply
* [PATCH v2] sh_eth: Optimization for RX excess judgement
From: Yoshihiro Kaneko @ 2014-12-08 10:48 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Simon Horman, Magnus Damm, linux-sh
From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
Both of 'boguscnt' and 'quota' have nearly meaning as the condition of
the reception loop.
In order to cut down redundant processing, this patch changes excess
judgement.
Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
---
This patch is based on net-next tree.
v2 [Yoshihiro Kaneko]
* re-spin for net-next.
* remove unneeded check of "quota".
drivers/net/ethernet/renesas/sh_eth.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index dbe8606..266c9b2 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1394,10 +1394,13 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
int entry = mdp->cur_rx % mdp->num_rx_ring;
int boguscnt = (mdp->dirty_rx + mdp->num_rx_ring) - mdp->cur_rx;
+ int limit;
struct sk_buff *skb;
u16 pkt_len = 0;
u32 desc_status;
+ boguscnt = min(boguscnt, *quota);
+ limit = boguscnt;
rxdesc = &mdp->rx_ring[entry];
while (!(rxdesc->status & cpu_to_edmac(mdp, RD_RACT))) {
desc_status = edmac_to_cpu(mdp, rxdesc->status);
@@ -1406,11 +1409,6 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
if (--boguscnt < 0)
break;
- if (*quota <= 0)
- break;
-
- (*quota)--;
-
if (!(desc_status & RDFEND))
ndev->stats.rx_length_errors++;
@@ -1501,6 +1499,8 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
sh_eth_write(ndev, EDRRR_R, EDRRR);
}
+ *quota -= limit - boguscnt + 1;
+
return *quota <= 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v2] sh_eth: Remove redundant alignment adjustment
From: Yoshihiro Kaneko @ 2014-12-08 10:46 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Simon Horman, Magnus Damm, linux-sh
From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
PTR_ALIGN macro after skb_reserve is redundant, because skb_reserve
function adjusts the alignment of skb->data.
Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
---
This series is based on net-next tree.
v2 [Yoshihiro Kaneko]
* re-spin for net-next.
drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index dbe8606..a0e737f 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1141,7 +1141,7 @@ static void sh_eth_ring_format(struct net_device *ndev)
/* RX descriptor */
rxdesc = &mdp->rx_ring[i];
- rxdesc->addr = virt_to_phys(PTR_ALIGN(skb->data, 4));
+ rxdesc->addr = virt_to_phys(skb->data);
rxdesc->status = cpu_to_edmac(mdp, RD_RACT | RD_RFP);
/* The size of the buffer is 16 byte boundary. */
@@ -1477,7 +1477,7 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
sh_eth_set_receive_align(skb);
skb_checksum_none_assert(skb);
- rxdesc->addr = virt_to_phys(PTR_ALIGN(skb->data, 4));
+ rxdesc->addr = virt_to_phys(skb->data);
}
if (entry >= mdp->num_rx_ring - 1)
rxdesc->status |=
--
1.9.1
^ permalink raw reply related
* RE;PO No 1,4,6 & 7
From: Lanox Industry bahrain @ 2014-12-08 10:12 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
Hello,
please, kindly quote your best prices for our attached order.Your company
came higly recommeded for this order.
For item No 1,4,6 & 7..give your best prices for we wish to make large order.
Add me on Skype for detailed discussion
Awaiting your urgent confirmation
Thanks & Best Regards
[-- Attachment #2: P O.zip --]
[-- Type: application/x-zip-compressed, Size: 403845 bytes --]
^ permalink raw reply
* is the commit 571dcfde2371 (net-next) a proper fix?
From: Andy Shevchenko @ 2014-12-08 10:23 UTC (permalink / raw)
To: Huacai Chen; +Cc: Giuseppe Cavallaro, David S. Miller, netdev
Hi!
It seems for me that commit 571dcfde2371 (stmmac: platform: fix default
values of the filter bins setting) is redundant (moreover, it could be a
cause of crash in some cases when there is no platform data defined in
case of CONFIG_OF).
In case of no OF the platform data should be provided by platform code
where the defaults are set. What did I miss?
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize
From: Luis Henriques @ 2014-12-08 10:19 UTC (permalink / raw)
To: Stefan Bader
Cc: Zoltan Kiss, Konrad Rzeszutek Wilk, Boris Ostrovsky, David Vrabel,
Wei Liu, Ian Campbell, netdev, linux-kernel, Paul Durrant,
xen-devel, Kamal Mostafa
In-Reply-To: <547C2CFC.7060908@canonical.com>
On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
> > There is a long known problem with the netfront/netback interface: if the guest
> > tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
> > it gets dropped. The reason is that netback maps these slots to a frag in the
> > frags array, which is limited by size. Having so many slots can occur since
> > compound pages were introduced, as the ring protocol slice them up into
> > individual (non-compound) page aligned slots. The theoretical worst case
> > scenario looks like this (note, skbs are limited to 64 Kb here):
> > linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
> > using 2 slots
> > first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
> > end and the beginning of a page, therefore they use 3 * 15 = 45 slots
> > last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
> > Although I don't think this 51 slots skb can really happen, we need a solution
> > which can deal with every scenario. In real life there is only a few slots
> > overdue, but usually it causes the TCP stream to be blocked, as the retry will
> > most likely have the same buffer layout.
> > This patch solves this problem by linearizing the packet. This is not the
> > fastest way, and it can fail much easier as it tries to allocate a big linear
> > area for the whole packet, but probably easier by an order of magnitude than
> > anything else. Probably this code path is not touched very frequently anyway.
> >
> > Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <Ian.Campbell@citrix.com>
> > Cc: Paul Durrant <paul.durrant@citrix.com>
> > Cc: netdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: xen-devel@lists.xenproject.org
>
> This does not seem to be marked explicitly as stable. Has someone already asked
> David Miller to put it on his stable queue? IMO it qualifies quite well and the
> actual change should be simple to pick/backport.
>
Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
Cheers,
--
Luís
> -Stefan
>
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 055222b..23359ae 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -628,9 +628,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > slots = DIV_ROUND_UP(offset + len, PAGE_SIZE) +
> > xennet_count_skb_frag_slots(skb);
> > if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
> > - net_alert_ratelimited(
> > - "xennet: skb rides the rocket: %d slots\n", slots);
> > - goto drop;
> > + net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\n",
> > + slots, skb->len);
> > + if (skb_linearize(skb))
> > + goto drop;
> > }
> >
> > spin_lock_irqsave(&queue->tx_lock, flags);
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
>
^ permalink raw reply
* RE: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: David Laight @ 2014-12-08 10:00 UTC (permalink / raw)
To: 'Eric Dumazet', David Miller
Cc: weiyang@linux.vnet.ibm.com, netdev@vger.kernel.org,
gideonn@mellanox.com, edumazet@google.com, amirv@mellanox.com
In-Reply-To: <1417844801.15618.30.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet
> On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
>
> > Guys, let's figure out what we are doing with this patch.
> > --
>
> Oh well, patch is fine, please apply it, thanks !
I'm not to sure that the patch doesn't generate a software byteswap
followed by a byteswapping write on ppc - clearly not ideal.
It might even generate back to back software byteswaps.
If the write to the doorbell register includes a byteswap on BE (ppc)
then there is no real value in keeping the value as BE.
OTOH ppc ought to have ways of doing IO writes without the byteswap
(and byteswapping accesses to non-io memory for that matter).
What happens on a BE system with BE peripherals is another matter.
David
^ permalink raw reply
* [PATCH net v2 5/5] libcxgbi: free skb after debug prints
From: kxie @ 2014-12-08 9:58 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v2 5/5] libcxgbi: free skb after debug prints
From: Karen Xie <kxie@chelsio.com>
The debug print was accessing the skb after it was freed.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/libcxgbi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 7da59c3..eb58afc 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
return err;
}
- kfree_skb(skb);
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX,
"itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n",
task->itt, skb, skb->len, skb->data_len, err);
+
+ kfree_skb(skb);
+
iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err);
iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED);
return err;
^ permalink raw reply related
* [PATCH net v2 0/5] cxgb4/cxgbi: misc. fixes for cxgb4i
From: kxie @ 2014-12-08 9:58 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v2 0/5] cxgb4/cxgbi: misc. fixes for cxgb4i
This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx messages and types of negative advice. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet.
Karen Xie (5):
cxgb4i: check if wr header is required when calculating tx credit
cxgb4/cxgb4i: set max. outgoing pdu length in the f/w
cxgb4i: handle non pdu-aligned rx data and additional types of negative advice
cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues
libcxgbi: fix the debug print accessing skb after it is freed
Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h).
v2 corrects the "CHECK"s flagged by checkpatch.pl --strict.
^ permalink raw reply
* [PATCH net v2 3/5] cxgb4i: handle non-pdu-aligned rx and additional types of negative advice
From: kxie @ 2014-12-08 9:58 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v2 3/5] cxgb4i: handle non-pdu-aligned rx data and additional types of negative advice
From: Karen Xie <kxie@chelsio.com>
- abort the connection upon receiving of cpl_rx_data, which means the pdu cannot be recovered from the tcp stream. This could be due to pdu header corruption.
- handle additional types of negative advice returned by h/w.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 34 +++++++++++++++++++++++++++++++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index b834bde..051adab 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -845,6 +845,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline int is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -866,7 +873,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -972,8 +979,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev, struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
@@ -1027,6 +1033,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1446,6 +1473,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] = {
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
^ permalink raw reply related
* [PATCH net v2 4/5] cxgb4i: use cxgb4's set_wr_txq() for setting tx queues
From: kxie @ 2014-12-08 9:58 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v2 4/5] cxgb4i: use cxgb4's set_wr_txq() for setting tx queues
From: Karen Xie <kxie@chelsio.com>
use cxgb4's set_wr_txq() to set the tx queue for a outgoing packet.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +++++-----------
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 051adab..3c99e5d 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK 0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -659,7 +653,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1551,7 +1545,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device *cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
^ 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