* Re: [PATCH net-next 0/4] cxgb4/cxgb4vf: T5 BAR2 and ethtool related fixes
From: David Miller @ 2014-12-09 18:32 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, kumaras
In-Reply-To: <1417615374-12961-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 3 Dec 2014 19:32:50 +0530
> This series adds new interface to calculate BAR2 SGE queue register address for
> cxgb4 and cxgb4vf driver and some more sge related fixes for T5. Also adds a
> patch which updates the FW version displayed by ethtool after firmware flash.
>
> The patches series is created against 'net-next' tree.
> And includes patches on cxgb4 and cxgb4vf driver.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] tipc: drop tx side permission checks
From: David Miller @ 2014-12-09 18:30 UTC (permalink / raw)
To: erik.hugne; +Cc: netdev, ying.xue, jon.maloy, richard.alpe, tipc-discussion
In-Reply-To: <1417614284-24125-1-git-send-email-erik.hugne@ericsson.com>
From: <erik.hugne@ericsson.com>
Date: Wed, 3 Dec 2014 14:44:44 +0100
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> Part of the old remote management feature is a piece of code
> that checked permissions on the local system to see if a certain
> operation was permitted, and if so pass the command to a remote
> node. This serves no purpose after the removal of remote management
> with commit 5902385a2440 ("tipc: obsolete the remote management
> feature") so we remove it.
>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
> Reviewed-by: Ying Xue <ying.xue@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next v2 2/2] rocker: fix eth_type type in struct rocker_ctrl
From: David Miller @ 2014-12-09 18:29 UTC (permalink / raw)
To: jiri; +Cc: netdev, sfeldma
In-Reply-To: <1417612494-3788-2-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 3 Dec 2014 14:14:54 +0100
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied.
^ permalink raw reply
* Re: [patch net-next v2 1/2] rocker: introduce be put/get variants and use it when appropriate
From: David Miller @ 2014-12-09 18:29 UTC (permalink / raw)
To: jiri; +Cc: netdev, sfeldma
In-Reply-To: <1417612494-3788-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 3 Dec 2014 14:14:53 +0100
> This kills the sparse warnings.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied.
^ permalink raw reply
* Re: [PATCH net] bnx2x: Limit 1G link enforcement
From: David Miller @ 2014-12-09 18:26 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, Ariel.Elior, Yaniv.Rosner
In-Reply-To: <1417608920-30867-1-git-send-email-Yuval.Mintz@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Wed, 3 Dec 2014 14:15:20 +0200
> From: Yaniv Rosner <Yaniv.Rosner@qlogic.com>
>
> Change 1G-SFP module detection by verifying not only that it's not
> compliant with 10G-Ethernet, but also that it's 1G-ethernet compliant.
>
> Signed-off-by: Yaniv Rosner <Yaniv.Rosner@qlogic.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git)] stmmac: fix max coal timer parameter
From: David Miller @ 2014-12-09 18:25 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1417606378-8179-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Wed, 3 Dec 2014 12:32:58 +0100
> This patch is to fix the max coalesce timer setting that can be provided
> by ethtool.
> The default value (STMMAC_COAL_TX_TIMER) was used in the set_coalesce helper
> instead of the max one (STMMAC_MAX_COAL_TX_TICK, so defined but not used).
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: sctp: use MAX_HEADER for headroom reserve in output path
From: David Miller @ 2014-12-09 18:24 UTC (permalink / raw)
To: dborkman; +Cc: linux-sctp, netdev, robert
In-Reply-To: <1417605238-9936-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Wed, 3 Dec 2014 12:13:58 +0100
> To accomodate for enough headroom for tunnels, use MAX_HEADER instead
> of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs
> of trinity an skb_under_panic() via SCTP output path (see reference).
> I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere
> in other protocols might be one possible cause for this.
>
> In any case, it looks like accounting on chunks themself seems to look
> good as the skb already passed the SCTP output path and did not hit
> any skb_over_panic(). Given tunneling was enabled in his .config, the
> headroom would have been expanded by MAX_HEADER in this case.
>
> Reported-by: Robert Święcki <robert@swiecki.net>
> Reference: https://lkml.org/lkml/2014/12/1/507
> Fixes: 594ccc14dfe4d ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Update FW version string to match FW binary version 1.12.25.0
From: David Miller @ 2014-12-09 18:22 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, kumaras
In-Reply-To: <1417589971-28524-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 3 Dec 2014 12:29:31 +0530
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net] cxgb4: Add a check for flashing FW using ethtool
From: David Miller @ 2014-12-09 18:21 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, kumaras
In-Reply-To: <1417587590-26248-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 3 Dec 2014 11:49:50 +0530
> Don't let T4 firmware flash on a T5 adapter and vice-versa
> using ethtool
>
> Based on original work by Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
>
> ---
> V2:
> Use bool for return value based on review comment by Sergei Shtylyov
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: remove useless spin_lock/spin_unlock
From: David Miller @ 2014-12-09 18:18 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev, eric.dumazet
In-Reply-To: <547E7594.7010301@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Wed, 3 Dec 2014 10:29:40 +0800
> xchg is atomic, so there is no necessary to use spin_lock/spin_unlock
> to protect it. At last, remove the redundant
> opt = xchg(&inet6_sk(sk)->opt, opt); statement.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> ---
> v2: remove the redundant opt = xchg(&inet6_sk(sk)->opt, opt); statement.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net v1 0/2] amd-xgbe: AMD XGBE driver fixes 2014-12-02
From: David Miller @ 2014-12-09 18:16 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20141203001642.17582.32777.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Tue, 2 Dec 2014 18:16:42 -0600
> The following series of patches includes two bug fixes. Unfortunately,
> the first patch will create a conflict when eventually merged into
> net-next but should be very easy to resolve.
>
> - Do not clear the interrupt bit in the xgbe_ring_data structure
> - Associate a Tx SKB with the proper xgbe_ring_data structure
>
> This patch series is based on net.
Series applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH net-next] amd-xgbe: IRQ names require allocated memory
From: David Miller @ 2014-12-09 18:13 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20141203000718.17370.31628.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Tue, 2 Dec 2014 18:07:18 -0600
> When requesting an irq, the name passed in must be (part of) allocated
> memory. The irq name was a local variable and resulted in random
> characters when listing /proc/interrupts. Add a character field to the
> xgbe_channel structure to hold the irq name and use that.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Applied.
^ permalink raw reply
* Re: [PATCH v7 2/3] net: Add Keystone NetCP ethernet driver
From: David Miller @ 2014-12-09 18:10 UTC (permalink / raw)
To: m-karicheri2-l0cyMroinI0
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A, sandeep_n-l0cyMroinI0,
santosh.shilimkar-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1417556503-22290-3-git-send-email-m-karicheri2-l0cyMroinI0@public.gmane.org>
From: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
Date: Tue, 2 Dec 2014 16:41:42 -0500
> +static void set_pkt_info_le(u32 buff, u32 buff_len, u32 ndesc,
> + struct knav_dma_desc *desc)
> +{
> + desc->buff_len = cpu_to_le32(buff_len);
> + desc->buff = cpu_to_le32(buff);
> + desc->next_desc = cpu_to_le32(ndesc);
> +}
The members of knav_dma_desc are "u32", so you are going to get tons of
static checker warnings from trying to assign cpu_to_le32()'s result
(which is a le32) into them.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU
From: Eric Dumazet @ 2014-12-09 18:07 UTC (permalink / raw)
To: Valdis Kletnieks; +Cc: John Fastabend, David S. Miller, linux-kernel, netdev
In-Reply-To: <6468.1418147500@turing-police.cc.vt.edu>
On Tue, Dec 9, 2014 at 9:51 AM, Valdis Kletnieks
<Valdis.Kletnieks@vt.edu> wrote:
> Spotted this in dmesg while investigating why my wireless broke
> sometime between next-20141201 and next-20141208. Probably not
> related, as wireless has been broken on several boot attempts of -1208,
> but this has popped only once....
>
> Looks like the fault of
>
> commit 46e5da40aec256155cfedee96dd21a75da941f2c
> Author: John Fastabend <john.fastabend@gmail.com>
> Date: Fri Sep 12 20:04:52 2014 -0700
Well, its a (harmless) typo : this should really be an
rcu_dereference_bh() instead of rcu_dereference()
^ permalink raw reply
* Re: [net_test_tools] udpflood: Add IPv6 support
From: David Miller @ 2014-12-09 18:05 UTC (permalink / raw)
To: kafai; +Cc: netdev
In-Reply-To: <1417545706-31249-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Tue, 2 Dec 2014 10:41:46 -0800
> This patch:
> 1. Add IPv6 support
> 2. Print timing for every 65536 fib insert operations to observe
> the gc effect (mostly for IPv6 fib).
Applied, thanks.
^ permalink raw reply
* RE: [net-next 05/13] i40e: add range check to i40e_aq_rc_to_posix
From: Nelson, Shannon @ 2014-12-09 17:35 UTC (permalink / raw)
To: Sergei Shtylyov, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <548705FC.6020805@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
> Sent: Tuesday, December 09, 2014 6:24 AM
> To: Kirsher, Jeffrey T; davem@davemloft.net
> Cc: Nelson, Shannon; netdev@vger.kernel.org; nhorman@redhat.com;
> sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 05/13] i40e: add range check to
> i40e_aq_rc_to_posix
>
> Hello.
>
> On 12/9/2014 2:22 PM, Jeff Kirsher wrote:
>
> > From: Shannon Nelson <shannon.nelson@intel.com>
>
> > Just to be sure, add a range check to avoid any possible
> > array index-out-of-bound issues.
>
> > Change-ID: I9323bee6732c2a47599816e1d6c6b3a1f8dcbf54
> > Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> > Acked-by: Michal Kosiarz <michal.kosiarz@intel.com>
> > Tested-by: Jim Young <jamesx.m.young@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_adminq.h | 2 ++
> > drivers/net/ethernet/intel/i40evf/i40e_adminq.h | 2 ++
> > 2 files changed, 4 insertions(+)
>
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > index 618fe96..4064b1e 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
> > @@ -136,6 +136,8 @@ static inline int i40e_aq_rc_to_posix(u16 aq_rc)
> > -EFBIG, /* I40E_AQ_RC_EFBIG */
> > };
> >
> > + if (aq_rc >= (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0])))
>
> There's ARRAY_SIZE() macro exactly for such computations. And parens
> around the last 'aq_to_posix' are not needed.
Yep, you're right. I'll see about getting Jeff to push a v2 of this patch soon.
Thanks,
sln
^ permalink raw reply
* Re: OVS Kernel Datapath development
From: Lori Jakab @ 2014-12-09 18:02 UTC (permalink / raw)
To: Pravin Shelar, netdev,
dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
In-Reply-To: <CALnjE+rn_Giv+8TM1_E2faBftRkivXMYHcjn-4Eq4Gu15r=CiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/08/2014 06:47 AM, Pravin Shelar wrote:
> Since the beginning OVS kernel datapath development is primarily done
> on external OVS repo. Now we have mostly synced upstream and external
> OVS. So we have decided to change this process. New process is as
> follows.
Patch series that have previous revisions already reviewed with the old
process should now switch to the new process? Or does the change apply
only to new patch series?
-Lori
>
> 1. OVS feature development that involves kernel datapath should be
> done on net-next tree datapath.
> 2. Such feature patch series should be posted on netdev and ovs-dev
> mailing list.
> 3. Once review is done for entire series, kernel and OVS userspace
> patches will be merged in respective repo.
> 4. After the merge developer is suppose to send patches for external
> kernel datapath along with old kernel compatibility code. So that we
> can keep external datapath insync.
>
>
> Thanks,
> Pravin.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [PATCH net] tcp: fix more NULL deref after prequeue changes
From: Eric Dumazet @ 2014-12-09 17:56 UTC (permalink / raw)
To: Dann Frazier, David S. Miller; +Cc: netdev
In-Reply-To: <1418145804.27198.0.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
When I cooked commit c3658e8d0f1 ("tcp: fix possible NULL dereference in
tcp_vX_send_reset()") I missed other spots we could deref a NULL
skb_dst(skb)
Again, if a socket is provided, we do not need skb_dst() to get a
pointer to network namespace : sock_net(sk) is good enough.
Reported-by: Dann Frazier <dann.frazier@canonical.com>
Bisected-by: Dann Frazier <dann.frazier@canonical.com>
Tested-by: Dann Frazier <dann.frazier@canonical.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: ca777eff51f7 ("tcp: remove dst refcount false sharing for prequeue mode")
---
net/ipv4/tcp_ipv4.c | 4 ++--
net/ipv6/tcp_ipv6.c | 28 ++++++++++++++--------------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 147be2024290..ef7089ca86e2 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -623,6 +623,7 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
arg.iov[0].iov_base = (unsigned char *)&rep;
arg.iov[0].iov_len = sizeof(rep.th);
+ net = sk ? sock_net(sk) : dev_net(skb_dst(skb)->dev);
#ifdef CONFIG_TCP_MD5SIG
hash_location = tcp_parse_md5sig_option(th);
if (!sk && hash_location) {
@@ -633,7 +634,7 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
* Incoming packet is checked with md5 hash with finding key,
* no RST generated if md5 hash doesn't match.
*/
- sk1 = __inet_lookup_listener(dev_net(skb_dst(skb)->dev),
+ sk1 = __inet_lookup_listener(net,
&tcp_hashinfo, ip_hdr(skb)->saddr,
th->source, ip_hdr(skb)->daddr,
ntohs(th->source), inet_iif(skb));
@@ -681,7 +682,6 @@ static void tcp_v4_send_reset(struct sock *sk, struct sk_buff *skb)
if (sk)
arg.bound_dev_if = sk->sk_bound_dev_if;
- net = dev_net(skb_dst(skb)->dev);
arg.tos = ip_hdr(skb)->tos;
ip_send_unicast_reply(net, skb, &TCP_SKB_CB(skb)->header.h4.opt,
ip_hdr(skb)->saddr, ip_hdr(skb)->daddr,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index dc495ae2ead0..c277951d783b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -787,16 +787,16 @@ static const struct tcp_request_sock_ops tcp_request_sock_ipv6_ops = {
.queue_hash_add = inet6_csk_reqsk_queue_hash_add,
};
-static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
- u32 tsval, u32 tsecr, int oif,
- struct tcp_md5sig_key *key, int rst, u8 tclass,
- u32 label)
+static void tcp_v6_send_response(struct sock *sk, struct sk_buff *skb, u32 seq,
+ u32 ack, u32 win, u32 tsval, u32 tsecr,
+ int oif, struct tcp_md5sig_key *key, int rst,
+ u8 tclass, u32 label)
{
const struct tcphdr *th = tcp_hdr(skb);
struct tcphdr *t1;
struct sk_buff *buff;
struct flowi6 fl6;
- struct net *net = dev_net(skb_dst(skb)->dev);
+ struct net *net = sk ? sock_net(sk) : dev_net(skb_dst(skb)->dev);
struct sock *ctl_sk = net->ipv6.tcp_sk;
unsigned int tot_len = sizeof(struct tcphdr);
struct dst_entry *dst;
@@ -946,7 +946,7 @@ static void tcp_v6_send_reset(struct sock *sk, struct sk_buff *skb)
(th->doff << 2);
oif = sk ? sk->sk_bound_dev_if : 0;
- tcp_v6_send_response(skb, seq, ack_seq, 0, 0, 0, oif, key, 1, 0, 0);
+ tcp_v6_send_response(sk, skb, seq, ack_seq, 0, 0, 0, oif, key, 1, 0, 0);
#ifdef CONFIG_TCP_MD5SIG
release_sk1:
@@ -957,13 +957,13 @@ release_sk1:
#endif
}
-static void tcp_v6_send_ack(struct sk_buff *skb, u32 seq, u32 ack,
- u32 win, u32 tsval, u32 tsecr, int oif,
+static void tcp_v6_send_ack(struct sock *sk, struct sk_buff *skb, u32 seq,
+ u32 ack, u32 win, u32 tsval, u32 tsecr, int oif,
struct tcp_md5sig_key *key, u8 tclass,
u32 label)
{
- tcp_v6_send_response(skb, seq, ack, win, tsval, tsecr, oif, key, 0, tclass,
- label);
+ tcp_v6_send_response(sk, skb, seq, ack, win, tsval, tsecr, oif, key, 0,
+ tclass, label);
}
static void tcp_v6_timewait_ack(struct sock *sk, struct sk_buff *skb)
@@ -971,7 +971,7 @@ static void tcp_v6_timewait_ack(struct sock *sk, struct sk_buff *skb)
struct inet_timewait_sock *tw = inet_twsk(sk);
struct tcp_timewait_sock *tcptw = tcp_twsk(sk);
- tcp_v6_send_ack(skb, tcptw->tw_snd_nxt, tcptw->tw_rcv_nxt,
+ tcp_v6_send_ack(sk, skb, tcptw->tw_snd_nxt, tcptw->tw_rcv_nxt,
tcptw->tw_rcv_wnd >> tw->tw_rcv_wscale,
tcp_time_stamp + tcptw->tw_ts_offset,
tcptw->tw_ts_recent, tw->tw_bound_dev_if, tcp_twsk_md5_key(tcptw),
@@ -986,10 +986,10 @@ static void tcp_v6_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
/* sk->sk_state == TCP_LISTEN -> for regular TCP_SYN_RECV
* sk->sk_state == TCP_SYN_RECV -> for Fast Open.
*/
- tcp_v6_send_ack(skb, (sk->sk_state == TCP_LISTEN) ?
+ tcp_v6_send_ack(sk, skb, (sk->sk_state == TCP_LISTEN) ?
tcp_rsk(req)->snt_isn + 1 : tcp_sk(sk)->snd_nxt,
- tcp_rsk(req)->rcv_nxt,
- req->rcv_wnd, tcp_time_stamp, req->ts_recent, sk->sk_bound_dev_if,
+ tcp_rsk(req)->rcv_nxt, req->rcv_wnd,
+ tcp_time_stamp, req->ts_recent, sk->sk_bound_dev_if,
tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->daddr),
0, 0);
}
^ permalink raw reply related
* linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU
From: Valdis Kletnieks @ 2014-12-09 17:51 UTC (permalink / raw)
To: John Fastabend, Eric Dumazet, David S. Miller; +Cc: linux-kernel, netdev
[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]
Spotted this in dmesg while investigating why my wireless broke
sometime between next-20141201 and next-20141208. Probably not
related, as wireless has been broken on several boot attempts of -1208,
but this has popped only once....
Looks like the fault of
commit 46e5da40aec256155cfedee96dd21a75da941f2c
Author: John Fastabend <john.fastabend@gmail.com>
Date: Fri Sep 12 20:04:52 2014 -0700
net: qdisc: use rcu prefix and silence sparse warnings
but I freely admit that exhausts my RCU debugging skills. :)
[ 104.743212] ===============================
[ 104.743214] [ INFO: suspicious RCU usage. ]
[ 104.743218] 3.18.0-next-20141208 #27 Tainted: G OE
[ 104.743219] -------------------------------
[ 104.743224] net/sched/sch_fq_codel.c:97 suspicious rcu_dereference_check() usage!
[ 104.743227]
other info that might help us debug this:
[ 104.743231]
rcu_scheduler_active = 1, debug_locks = 1
[ 104.743236] 4 locks held by unbound/1873:
[ 104.743239] #0: (rcu_read_lock_bh){......}, at: [<ffffffff8a537066>] rcu_lock_acquire+0x0/0x22
[ 104.743257] #1: (rcu_read_lock_bh){......}, at: [<ffffffff8a4ebd44>] rcu_lock_acquire+0x0/0x22
[ 104.743274] #2: (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.....}, at: [<ffffffff8a4f3ea4>] __dev_queue_xmit+0x32a/0x66a
[ 104.743292] #3: (&qdisc_tx_lock){+.-...}, at: [<ffffffff8a4f3ead>] __dev_queue_xmit+0x333/0x66a
[ 104.743302]
stack backtrace:
[ 104.743307] CPU: 2 PID: 1873 Comm: unbound Tainted: G OE 3.18.0-next-20141208 #27
[ 104.743309] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014
[ 104.743312] 0000000000000001 ffff8800b9f3f978 ffffffff8a6ba925 ffff880223bac210
[ 104.743317] 0000000000000001 ffff8800b9f3f9a8 ffffffff8a07f124 ffff8800b9ce4e00
[ 104.743323] ffff880223fea600 0000000000000000 ffff8800c6e2c000 ffff8800b9f3f9f8
[ 104.743329] Call Trace:
[ 104.743336] [<ffffffff8a6ba925>] dump_stack+0x50/0xa8
[ 104.743343] [<ffffffff8a07f124>] lockdep_rcu_suspicious+0xea/0xf3
[ 104.743348] [<ffffffff8a514903>] fq_codel_enqueue+0x79/0x21c
[ 104.743353] [<ffffffff8a6c5228>] ? _raw_spin_lock+0x37/0x3f
[ 104.743357] [<ffffffff8a4f3fb5>] __dev_queue_xmit+0x43b/0x66a
[ 104.743362] [<ffffffff8a4f41ef>] dev_queue_xmit+0xb/0xd
[ 104.743367] [<ffffffff8a537beb>] ip_finish_output2+0x42b/0x46c
[ 104.743371] [<ffffffff8a53838f>] ip_finish_output+0x13c/0x144
[ 104.743376] [<ffffffff8a5393f1>] ip_output+0x4c/0x70
[ 104.743381] [<ffffffff8a538d92>] ip_local_out_sk+0x54/0x5f
[ 104.743385] [<ffffffff8a539c2f>] ip_send_skb+0x12/0x37
[ 104.743390] [<ffffffff8a55d145>] udp_send_skb+0x176/0x1db
[ 104.743394] [<ffffffff8a55d839>] udp_sendmsg+0x63e/0x87c
[ 104.743398] [<ffffffff8a537379>] ? skb_set_owner_w+0x56/0x56
[ 104.743404] [<ffffffff8a09011d>] ? __rcu_read_unlock+0xf5/0xfd
[ 104.743408] [<ffffffff8a568135>] ? rcu_read_unlock+0x3e/0x5d
[ 104.743413] [<ffffffff8a568af9>] inet_sendmsg+0x3d/0x66
[ 104.743419] [<ffffffff8a4d6a4b>] __sock_sendmsg_nosec+0x25/0x27
[ 104.743422] [<ffffffff8a4d80da>] sock_sendmsg+0x5a/0x7b
[ 104.743429] [<ffffffff8a12581b>] ? might_fault+0xae/0xb0
[ 104.743433] [<ffffffff8a4d6c22>] ? audit_sockaddr+0x2b/0x44
[ 104.743437] [<ffffffff8a4da1ff>] SYSC_sendto+0x119/0x15c
[ 104.743443] [<ffffffff8a00e2b5>] ? do_audit_syscall_entry+0xb8/0xc7
[ 104.743447] [<ffffffff8a4da85d>] SyS_sendto+0x9/0xb
[ 104.743453] [<ffffffff8a6c5fd2>] system_call_fastpath+0x12/0x17
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply
* [PATCH 1/1] net: dsa: Fix of kernel panic in case of missing PHY.
From: Andrey Volkov @ 2014-12-09 17:31 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli
Fix of kernel panic in case of missing PHY.
Signed-off-by: Andrey Volkov <andrey.volkov@nexvision.fr>
---
net/dsa/slave.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 528380a..6f89caa 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -512,7 +512,7 @@ static int dsa_slave_fixed_link_update(struct net_device *dev,
}
/* slave device setup *******************************************************/
-static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
+static int dsa_slave_phy_setup(struct dsa_slave_priv *p,
struct net_device *slave_dev)
{
struct dsa_switch *ds = p->parent;
@@ -533,7 +533,7 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
ret = of_phy_register_fixed_link(port_dn);
if (ret) {
netdev_err(slave_dev, "failed to register fixed PHY\n");
- return;
+ return ret;
}
phy_is_fixed = true;
phy_dn = port_dn;
@@ -555,12 +555,17 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
*/
if (!p->phy) {
p->phy = ds->slave_mii_bus->phy_map[p->port];
- phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
+ if(p->phy)
+ phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
p->phy_interface);
+ else
+ return -ENODEV;
+
} else {
netdev_info(slave_dev, "attached PHY at address %d [%s]\n",
p->phy->addr, p->phy->drv->name);
}
+ return 0;
}
int dsa_slave_suspend(struct net_device *slave_dev)
@@ -653,7 +658,13 @@ dsa_slave_create(struct dsa_switch *ds, struct device *parent,
p->old_link = -1;
p->old_duplex = -1;
- dsa_slave_phy_setup(p, slave_dev);
+ ret = dsa_slave_phy_setup(p, slave_dev);
+ if (ret) {
+ netdev_err(master, "error %d registering interface %s\n",
+ ret, slave_dev->name);
+ free_netdev(slave_dev);
+ return NULL;
+ }
ret = register_netdev(slave_dev);
if (ret) {
^ permalink raw reply related
* Re: [ovs-dev] OVS Kernel Datapath development
From: Pravin Shelar @ 2014-12-09 17:34 UTC (permalink / raw)
To: thomasfherbert; +Cc: Thomas Graf, dev@openvswitch.org, netdev
In-Reply-To: <54870E56.30305@gmail.com>
On Tue, Dec 9, 2014 at 6:59 AM, Thomas F Herbert
<thomasfherbert@gmail.com> wrote:
> Thanks.
>
> What is the impact on a developer submitting a patch. Do we now submit the
> linux datapath portion of the patch to both netdev and ovs-dev?
>
Yes, if a feature needs kernel datapath changes the feature series
should be posted on both mailing lists.
> --Tom
>
>
> On 12/8/14, 1:30 PM, Pravin Shelar wrote:
>>
>> On Mon, Dec 8, 2014 at 9:15 AM, Thomas Graf <tgraf@noironetworks.com>
>> wrote:
>>>
>>> On 12/07/14 at 08:47pm, Pravin Shelar wrote:
>>>>
>>>> Since the beginning OVS kernel datapath development is primarily done
>>>> on external OVS repo. Now we have mostly synced upstream and external
>>>> OVS. So we have decided to change this process. New process is as
>>>> follows.
>>>>
>>>> 1. OVS feature development that involves kernel datapath should be
>>>> done on net-next tree datapath.
>>>> 2. Such feature patch series should be posted on netdev and ovs-dev
>>>> mailing list.
>>>> 3. Once review is done for entire series, kernel and OVS userspace
>>>> patches will be merged in respective repo.
>>>> 4. After the merge developer is suppose to send patches for external
>>>> kernel datapath along with old kernel compatibility code. So that we
>>>> can keep external datapath insync.
>>>
>>> +1
>>>
>>> Just to be clear, by respective repo do you mean net-next/net or will
>>> you maintain a net-next branch on git.kernel.org and continue doing
>>> pull requests?
>>
>> OVS patches will directly go to net-next/net tree. I am not planning
>> on maintaining any tree on git.kernel.org.
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>
>
>
> --
> Thomas F. Herbert
>
^ permalink raw reply
* [PATCH net v3 3/6] cxgb4i: additional types of negative advice
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 3/6] cxgb4i: additional types of negative advice
From: Karen Xie <kxie@chelsio.com>
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as negative advice.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index b834bde..e7a26c0 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 bool 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);
^ permalink raw reply related
* [PATCH net v3 0/6] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 0/6] cxgb4/cxgbi: misc. fixes for cxgb4i
This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet.
Karen Xie (6):
cxgb4i: check if wr header is required when calculating tx credit
cxgb4/cxgb4i: set max. outgoing pdu length in the f/w
cxgb4i: add more types of negative advice
cxgb4i: handle non pdu-aligned rx data
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.
v3 splits the 3rd patch from v2 to two seperate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool as recommended by Sergei.
^ permalink raw reply
* [PATCH net v3 1/6] cxgb4i: fix tx credit calculation
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 1/6] cxgb4i: fix tx credit calculation
From: Karen Xie <kxie@chelsio.com>
- Only data skbs need the wr header added while control skbs do not. Make sure they are treated differently.
- Any credit related checking should be done before adding the wr header.
- Fixed compiler warning resulted from added cxgbi_skb_test_flag() call in is_ofld_imm().
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 26 +++++++++++++++++---------
drivers/scsi/cxgbi/libcxgbi.h | 4 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..5c3f15d 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -173,8 +173,12 @@ static int push_tx_frames(struct cxgbi_sock *, int);
*/
static inline int is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int length = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ length += sizeof(struct fw_ofld_tx_data_wr);
+
+ return length <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -544,15 +548,17 @@ static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
- req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
-
if (is_ofld_imm(skb)) {
+ req = (struct fw_ofld_tx_data_wr *)__skb_push(skb,
+ sizeof(*req));
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
req->flowid_len16 = htonl(FW_WR_FLOWID(csk->tid) |
FW_WR_LEN16(credits));
} else {
+ req = (struct fw_ofld_tx_data_wr *)__skb_push(skb,
+ sizeof(*req));
req->op_to_immdlen =
cpu_to_be32(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
@@ -597,12 +603,14 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
- 16);
+ credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr), 16);
if (csk->wr_cred < credits_needed) {
log_debug(1 << CXGBI_DBG_PDU_TX,
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff *skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
^ permalink raw reply related
* [PATCH net v3 2/6] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie @ 2014-12-09 17:32 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v3 2/6] cxgb4/cxgb4i: set the max. pdu length in firmware.
From: Karen Xie <kxie@chelsio.com>
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 1
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 ++++++++++++++++++-------
2 files changed, 52 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5c3f15d..b834bde 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *, struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+ * Return the number of 16-byte credits used by the FlowC request.
+ * Pass back the nparams and actual FlowC length if requested.
+ */
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -600,6 +627,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -612,6 +640,17 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
credits_needed += DIV_ROUND_UP(
sizeof(struct fw_ofld_tx_data_wr), 16);
+ /*
+ * Assumes the initial credits is large enough to support
+ * fw_flowc_wr plus largest possible first payload
+ */
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ flowclen16 = send_tx_flowc_wr(csk);
+ csk->wr_cred -= flowclen16;
+ csk->wr_una_cred += flowclen16;
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
if (csk->wr_cred < credits_needed) {
log_debug(1 << CXGBI_DBG_PDU_TX,
"csk 0x%p, skb %u/%u, wr %d < %u.\n",
@@ -621,7 +660,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
}
__skb_unlink(skb, &csk->write_queue);
set_queue(skb, CPL_PRIORITY_DATA, csk);
- skb->csum = credits_needed;
+ skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
cxgbi_sock_enqueue_wr(csk, skb);
@@ -632,12 +671,6 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
csk->wr_cred, csk->wr_una_cred);
if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR))) {
- if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
- send_tx_flowc_wr(csk);
- skb->csum += 5;
- csk->wr_cred -= 5;
- csk->wr_una_cred += 5;
- }
len += cxgbi_ulp_extra_len(cxgbi_skcb_ulp_mode(skb));
make_tx_data_wr(csk, skb, dlen, len, credits_needed,
req_completion);
^ 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