* Re: xen-netback: make feature-rx-notify mandatory -- Breaks stubdoms
From: Ian Campbell @ 2014-12-10 16:20 UTC (permalink / raw)
To: David Vrabel
Cc: John, Xen-devel@lists.xen.org, Wei Liu, netdev@vger.kernel.org
In-Reply-To: <548866D9.5050900@citrix.com>
On Wed, 2014-12-10 at 15:29 +0000, David Vrabel wrote:
> On 10/12/14 15:07, Ian Campbell wrote:
> > On Wed, 2014-12-10 at 14:12 +0000, David Vrabel wrote:
> >> On 10/12/14 13:42, John wrote:
> >>> David,
> >>>
> >>> This patch you put into 3.18.0 appears to break the latest version of
> >>> stubdomains. I found this out today when I tried to update a machine to
> >>> 3.18.0 and all of the domUs crashed on start with the dmesg output like
> >>> this:
> >>
> >> Cc'ing the lists and relevant netback maintainers.
> >>
> >> I guess the stubdoms are using minios's netfront? This is something I
> >> forgot about when deciding if it was ok to make this feature mandatory.
> >
> > Oh bum, me too :/
> >
> >> The patch cannot be reverted as it's a prerequisite for a critical
> >> (security) bug fix. I am also unconvinced that the no-feature-rx-notify
> >> support worked correctly anyway.
> >>
> >> This can be resolved by:
> >>
> >> - Fixing minios's netfront to support feature-rx-notify. This should be
> >> easy but wouldn't help existing Xen deployments.
> >
> > I think this is worth doing in its own right, but as you say it doesn't
> > help existing users.
> >
> >> - Reimplement feature-rx-notify support. I think the easiest way is to
> >> queue packets on the guest Rx internal queue with a short expiry time.
> >
> > Right, I don't think we especially need to make this case good (so long
> > as it doesn't reintroduce a security hole!).
> >
> > In principal we aren't really obliged to queue at all, but since all the
> > infrastructure for queuing and timing out all exists I suppose it would
> > be simple enough to implement and a bit less harsh.
> >
> > Given we now have XENVIF_RX_QUEUE_BYTES and rx_drain_timeout_jiffies we
> > don't have the infinite queue any more. So does the expiry in this case
> > actually need to be shorter than the norm? Does it cause any extra
> > issues to keep them around for tx_drain_timeout_jiffies rather than some
> > shorter time?
>
> If the internal guest rx queue fills and the (host) tx queue is stopped,
> it will take tx_drain_timeout for the thread to wake up and notice if
> the frontend placed any rx requests on the ring. This could potentially
> end up where you shovel 512k through stall for 10 s, put another 512k
> through, stall for 10 s again and so on.
Ah, true, that's not so great.
What about if we don't queue at all(*) if rx-notify isn't supported, i.e
just drop the packet on the floor in start_xmit if the ring is full?
Would that be so bad? It would surely be simple...
(*) Not counting the "queue" which is the ring itself.
> The rx stall detection will also need to be disabled since there would
> be no way for the frontend to signal rx ready.
Agreed.
Could be trivially argued to be safe if we were just dropping packets on
ring overflow...
Ian.
^ permalink raw reply
* Re: [PATCH V1 net-next 03/10] net/mlx4_core: Use tasklet for user-space CQ completion events
From: Matan Barak @ 2014-12-10 15:47 UTC (permalink / raw)
To: Eric Dumazet, Or Gerlitz
Cc: David S. Miller, netdev, Amir Vadai, Tal Alon, Jack Morgenstein
In-Reply-To: <1418225599.27198.18.camel@edumazet-glaptop2.roam.corp.google.com>
On 12/10/2014 5:33 PM, Eric Dumazet wrote:
> On Wed, 2014-12-10 at 15:09 +0200, Or Gerlitz wrote:
>> From: Matan Barak <matanb@mellanox.com>
>>
>> Previously, we've fired all our completion callbacks straight from our ISR.
>>
>> Some of those callbacks were lightweight (for example, mlx4_en's and
>> IPoIB napi callbacks), but some of them did more work (for example,
>> the user-space RDMA stack uverbs' completion handler). Besides that,
>> doing more than the minimal work in ISR is generally considered wrong,
>> it could even lead to a hard lockup of the system. Since when a lot
>> of completion events are generated by the hardware, the loop over those
>> events could be so long, that we'll get into a hard lockup by the system
>> watchdog.
>
> ...
>
>> +#define TASKLET_THRESHOLD 1000
>> +
>> +void mlx4_cq_tasklet_cb(unsigned long data)
>> +{
>> + unsigned long flags;
>> + unsigned int i = 0;
>> + struct mlx4_eq_tasklet *ctx = (struct mlx4_eq_tasklet *)data;
>> + struct mlx4_cq *mcq, *temp;
>> +
>> + spin_lock_irqsave(&ctx->lock, flags);
>> + list_splice_tail_init(&ctx->list, &ctx->process_list);
>> + spin_unlock_irqrestore(&ctx->lock, flags);
>> +
>> + list_for_each_entry_safe(mcq, temp, &ctx->process_list, tasklet_ctx.list) {
>> + list_del_init(&mcq->tasklet_ctx.list);
>> + mcq->tasklet_ctx.comp(mcq);
>> + if (atomic_dec_and_test(&mcq->refcount))
>> + complete(&mcq->free);
>> + if (++i == TASKLET_THRESHOLD)
>> + break;
>> + }
>> +
>> + if (i == TASKLET_THRESHOLD)
>> + tasklet_schedule(&ctx->task);
>> +}
>> +
>
> What is the max duration of doing this loop up to 1000 times ?
>
> I suspect it might be too long, but not necessarily detected by
> conventional watchdog.
>
> __do_softirq() uses both a counter and a test against jiffies, with a 2
> ms limit.
You're right - we'll measure it accurately, but I think it took over 2ms
(on a system with 400 CQs opened), including the spin_lock on the
list_splice.
We'll add the jiffies test to V2.
Thanks.
>
> Thanks.
>
>
^ permalink raw reply
* [PATCH net v6 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie <kxie@chelsio.com>
make sure any tx credit related checking is done before adding the wr header.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index f119a67..abee611 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -547,10 +547,11 @@ static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
struct fw_ofld_tx_data_wr *req;
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
+ bool imm = is_ofld_imm(skb);
req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
- if (is_ofld_imm(skb)) {
+ if (imm) {
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
^ permalink raw reply related
* [PATCH net v6 7/7] libcxgbi: free skb after debug prints
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 7/7] 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 v6 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 0/7] 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 (7):
cxgb4i: fix tx immediate data credit check
cxgb4i: fix credit check for tx_data_wr
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 separate 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.
v4 -- please ignore.
v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr().
v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch.
^ permalink raw reply
* [PATCH net v6 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 1/7] cxgb4i: fix tx immediate data credit check
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.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 +++++++++++++++-------
drivers/scsi/cxgbi/libcxgbi.h | 4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..f119a67 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -171,10 +171,14 @@ static int push_tx_frames(struct cxgbi_sock *, int);
* Returns true if a packet can be sent as an offload WR with immediate
* data. We currently use the same limit as for Ethernet packets.
*/
-static inline int is_ofld_imm(const struct sk_buff *skb)
+static inline bool is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int len = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ len += sizeof(struct fw_ofld_tx_data_wr);
+
+ return len <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -597,11 +601,15 @@ 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),
+ 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) {
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 v6 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 3/7] 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/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 +++++++++++++++++++++++++++---------
1 files changed, 51 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 abee611..5f31eb7 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,
@@ -599,6 +626,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))
@@ -613,6 +641,17 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
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",
@@ -622,7 +661,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);
@@ -633,12 +672,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
* [PATCH net v6 4/7] cxgb4i: additional types of negative advice
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 4/7] 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 5f31eb7..2880f200 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -846,6 +846,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;
@@ -867,7 +874,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);
@@ -973,8 +980,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 v6 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 5/7] cxgb4i: handle non-pdu-aligned rx data
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 generally is due to pdu header corruption.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 2880f200..dff7345 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1034,6 +1034,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;
@@ -1453,6 +1474,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 v6 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie @ 2014-12-10 16:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v6 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie <kxie@chelsio.com>
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet. Remove the similar function in cxgb4i.
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 dff7345..6aa50fc 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",
@@ -660,7 +654,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;
@@ -1552,7 +1546,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
* [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-10 16:23 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: stephen@networkplumber.org, Fastabend, John R, jiri@resnulli.us,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
From: Marco Varlese <marco.varlese@intel.com>
Switch hardware offers a list of attributes that are configurable
on a per port basis.
This patch provides a mechanism to configure switch ports by adding
an NDO for setting specific values to specific attributes.
There will be a separate patch that extends iproute2 to call the
new NDO.
Signed-off-by: Marco Varlese <marco.varlese@intel.com>
---
include/linux/netdevice.h | 5 +++++
include/uapi/linux/if_link.h | 1 +
net/core/rtnetlink.c | 33 +++++++++++++++++++++++++++++++++
3 files changed, 39 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c31f74d..4881c7b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1027,6 +1027,9 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
* int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
* Called to notify switch device port of bridge port STP
* state change.
+ * int (*ndo_switch_port_set_cfg)(struct net_device *dev,
+ * u32 attr, u64 value);
+ * Called to set specific switch ports attributes.
*/
struct net_device_ops {
int (*ndo_init)(struct net_device *dev);
@@ -1185,6 +1188,8 @@ struct net_device_ops {
struct netdev_phys_item_id *psid);
int (*ndo_switch_port_stp_update)(struct net_device *dev,
u8 state);
+ int (*ndo_switch_port_set_cfg)(struct net_device *dev,
+ u32 attr, u64 value);
#endif
};
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index f7d0d2d..b35c314 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -146,6 +146,7 @@ enum {
IFLA_PHYS_PORT_ID,
IFLA_CARRIER_CHANGES,
IFLA_PHYS_SWITCH_ID,
+ IFLA_SWITCH_PORT_CFG,
__IFLA_MAX
};
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index eaa057f..e1be9ca 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1389,6 +1389,25 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
return 0;
}
+#ifdef CONFIG_NET_SWITCHDEV
+static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
+{
+ int rem, err = -EINVAL;
+ struct nlattr *v;
+ const struct net_device_ops *ops = dev->netdev_ops;
+
+ nla_for_each_nested(v, attr, rem) {
+ u32 op = nla_type(v);
+ u64 value = nla_get_u64(v);
+
+ err = ops->ndo_switch_port_set_cfg(dev, op, value);
+ if (err)
+ break;
+ }
+ return err;
+}
+#endif
+
static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
{
int rem, err = -EINVAL;
@@ -1740,6 +1759,20 @@ static int do_setlink(const struct sk_buff *skb,
status |= DO_SETLINK_NOTIFY;
}
}
+#ifdef CONFIG_NET_SWITCHDEV
+ if (tb[IFLA_SWITCH_PORT_CFG]) {
+ err = -EOPNOTSUPP;
+ if (!ops->ndo_switch_port_set_cfg)
+ goto errout;
+ if (!ops->ndo_switch_parent_id_get)
+ goto errout;
+ err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
+ if (err < 0)
+ goto errout;
+
+ status |= DO_SETLINK_NOTIFY;
+ }
+#endif
err = 0;
errout:
--
1.8.5.3
^ permalink raw reply related
* RE: [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie @ 2014-12-10 16:27 UTC (permalink / raw)
To: Sergei Shtylyov, linux-scsi@vger.kernel.org,
netdev@vger.kernel.org
Cc: Hariprasad S, Anish Bhatt, hch@infradead.org,
James.Bottomley@HansenPartnership.com, michaelc@cs.wisc.edu,
davem@davemloft.net
In-Reply-To: <54885415.4020105@cogentembedded.com>
Thanks for the review. V6 has been submitted to address this.
-----Original Message-----
From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
Sent: Wednesday, December 10, 2014 6:09 AM
To: Karen Xie; linux-scsi@vger.kernel.org; netdev@vger.kernel.org
Cc: Hariprasad S; Anish Bhatt; hch@infradead.org; James.Bottomley@HansenPartnership.com; michaelc@cs.wisc.edu; davem@davemloft.net
Subject: Re: [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr
Hello.
On 12/10/2014 4:43 AM, Karen Xie wrote:
> [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr
> From: Karen Xie <kxie@chelsio.com>
> make sure any tx credit related checking is done before adding the wr header.
> Signed-off-by: Karen Xie <kxie@chelsio.com>
> ---
> drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
> diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> index f119a67..56dbd25 100644
> --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> @@ -547,15 +547,16 @@ static inline void make_tx_data_wr(struct
> cxgbi_sock *csk, struct sk_buff *skb,
[...]
> req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
> - FW_WR_COMPL(1) |
> - FW_WR_IMMDLEN(dlen));
> + FW_WR_COMPL(1) |
> + FW_WR_IMMDLEN(dlen));
> req->flowid_len16 = htonl(FW_WR_FLOWID(csk->tid) |
> - FW_WR_LEN16(credits));
> + FW_WR_LEN16(credits));
The above looks like unrelated cleanup, worth putting in a separate net-next patch...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver
From: Arnd Bergmann @ 2014-12-10 16:36 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Miller, mark.rutland, devicetree, f.fainelli, linux,
eric.dumazet, sergei.shtylyov, netdev, agraf, xuwei5,
David.Laight, dingtianhong, zhangfei.gao
In-Reply-To: <20141210.110732.519666115784722516.davem@davemloft.net>
On Wednesday 10 December 2014 11:07:32 David Miller wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed, 10 Dec 2014 10:35:20 +0100
>
> > On Wednesday 10 December 2014 14:45:29 Ding Tianhong wrote:
> >>
> >> Miss this code, I think the best way is skb_orphan(skb), just like the cxgb3 drivers, some hardware
> >> didn't use the tx inq to free dmad Tx packages.
> >
> > The problem with skb_orphan is that you are telling the network stack that
> > the packet is now out of its reach and it will no longer be able to take
> > queued packets into account.
>
> skb_orphan() also does not release netfilter resources attached to the
> packet.
>
> Really, all drivers must free TX SKBs in a small, finite, amount of
> time after submission.
>
> There is no way around this.
I see. Do you see a problem with returning early from napi->poll()
without calling napi_complete() when the TX queue remains full at
the end of the poll function?
Or is there any better alternative for broken hardware that lacks
a TX-complete interrupt?
Arnd
^ permalink raw reply
* [PATCH net-next] cxgb4vf: Fix sparse warnings
From: Hariprasad Shenai @ 2014-12-10 16:47 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
Fixes sparse warnings introduced in commit e85c9a7abfa407ed ("cxgb4/cxgb4vf: Add
code to calculate T5 BAR2 Offsets for SGE Queue Registers") and
df64e4d38c904dd3 ("cxgb4/cxgb4vf: Use new interfaces to calculate BAR2 SGE Queue
Register addresses") and few old ones
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 8 ++++----
drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index f7fd131..c47ef3d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -1002,8 +1002,8 @@ static inline void ring_tx_db(struct adapter *adapter, struct sge_txq *tq,
unsigned int index = (tq->pidx
? (tq->pidx - 1)
: (tq->size - 1));
- __be64 *src = (__be64 *)&tq->desc[index];
- __be64 __iomem *dst = (__be64 *)(tq->bar2_addr +
+ u64 *src = (u64 *)&tq->desc[index];
+ __be64 __iomem *dst = (__be64 __iomem *)(tq->bar2_addr +
SGE_UDB_WCDOORBELL);
unsigned int count = EQ_UNIT / sizeof(__be64);
@@ -1251,8 +1251,8 @@ int t4vf_eth_xmit(struct sk_buff *skb, struct net_device *dev)
BUG_ON(DIV_ROUND_UP(ETHTXQ_MAX_HDR, TXD_PER_EQ_UNIT) > 1);
wr = (void *)&txq->q.desc[txq->q.pidx];
wr->equiq_to_len16 = cpu_to_be32(wr_mid);
- wr->r3[0] = cpu_to_be64(0);
- wr->r3[1] = cpu_to_be64(0);
+ wr->r3[0] = cpu_to_be32(0);
+ wr->r3[1] = cpu_to_be32(0);
skb_copy_from_linear_data(skb, (void *)wr->ethmacdst, fw_hdr_copy_len);
end = (u64 *)wr + flits;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
index 02e8833..62bd251 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
@@ -209,10 +209,10 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
if (rpl) {
/* request bit in high-order BE word */
- WARN_ON((be32_to_cpu(*(const u32 *)cmd)
+ WARN_ON((be32_to_cpu(*(const __be32 *)cmd)
& FW_CMD_REQUEST_F) == 0);
get_mbox_rpl(adapter, rpl, size, mbox_data);
- WARN_ON((be32_to_cpu(*(u32 *)rpl)
+ WARN_ON((be32_to_cpu(*(__be32 *)rpl)
& FW_CMD_REQUEST_F) != 0);
}
t4_write_reg(adapter, mbox_ctl,
@@ -486,7 +486,7 @@ int t4_bar2_sge_qregs(struct adapter *adapter,
* o The BAR2 Queue ID.
* o The BAR2 Queue ID Offset into the BAR2 page.
*/
- bar2_page_offset = ((qid >> qpp_shift) << page_shift);
+ bar2_page_offset = (u64)((qid >> qpp_shift) << page_shift);
bar2_qid = qid & qpp_mask;
bar2_qid_offset = bar2_qid * SGE_UDB_SIZE;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] stmmac: platform: adjust messages and move to dev level
From: David Miller @ 2014-12-10 16:44 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1418208471.17201.56.camel@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed, 10 Dec 2014 12:47:51 +0200
> On Tue, 2014-12-09 at 18:28 -0500, David Miller wrote:
>> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Date: Tue, 9 Dec 2014 11:59:13 +0200
>>
>> > This patch amendes error and warning messages across the platform driver. It
>> > includes the following changes:
>> > - remove unneccessary message when no memory is available
>> > - change info level to warn in the validation functions
>> > - append \n to the end of messages
>> > - change pr_* macros to dev_*
>> >
>> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>>
>> This does not apply to the net-next tree, please respin.
>
> Yeah, maybe because the fix (*) you mentioned in previos mail is not in
> net-next by some reason?
>
> (*) I refer to commit 28603d13997e2ef47f18589cc9a44553aad49c86
It's in the 'net' tree which hasn't been merged into net-next.
^ permalink raw reply
* RE: [PATCH net-next] cxgb4vf: Fix sparse warnings
From: David Laight @ 2014-12-10 16:47 UTC (permalink / raw)
To: 'Hariprasad Shenai', netdev@vger.kernel.org
Cc: davem@davemloft.net, leedom@chelsio.com, anish@chelsio.com,
nirranjan@chelsio.com, kumaras@chelsio.com
In-Reply-To: <1418230039-13219-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai
> Fixes sparse warnings introduced in commit e85c9a7abfa407ed ("cxgb4/cxgb4vf: Add
> code to calculate T5 BAR2 Offsets for SGE Queue Registers") and
> df64e4d38c904dd3 ("cxgb4/cxgb4vf: Use new interfaces to calculate BAR2 SGE Queue
> Register addresses") and few old ones
>
...
> diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
> b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
> index 02e8833..62bd251 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
> @@ -209,10 +209,10 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
>
> if (rpl) {
> /* request bit in high-order BE word */
> - WARN_ON((be32_to_cpu(*(const u32 *)cmd)
> + WARN_ON((be32_to_cpu(*(const __be32 *)cmd)
> & FW_CMD_REQUEST_F) == 0);
> get_mbox_rpl(adapter, rpl, size, mbox_data);
> - WARN_ON((be32_to_cpu(*(u32 *)rpl)
> + WARN_ON((be32_to_cpu(*(__be32 *)rpl)
> & FW_CMD_REQUEST_F) != 0);
Better to byteswap the constant.
Also, it looks like the types of 'rpl' and 'cmd' should be fixed
so that the casts themselves aren't needed.
> }
> t4_write_reg(adapter, mbox_ctl,
> @@ -486,7 +486,7 @@ int t4_bar2_sge_qregs(struct adapter *adapter,
> * o The BAR2 Queue ID.
> * o The BAR2 Queue ID Offset into the BAR2 page.
> */
> - bar2_page_offset = ((qid >> qpp_shift) << page_shift);
> + bar2_page_offset = (u64)((qid >> qpp_shift) << page_shift);
That doesn't look like the right place for a cast to u64.
Not that it is at all clear why you've added it.
David
> bar2_qid = qid & qpp_mask;
> bar2_qid_offset = bar2_qid * SGE_UDB_SIZE;
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Jiri Pirko @ 2014-12-10 16:50 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, stephen@networkplumber.org,
Fastabend, John R, roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104AC3257@IRSMSX108.ger.corp.intel.com>
Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com wrote:
>From: Marco Varlese <marco.varlese@intel.com>
>
>Switch hardware offers a list of attributes that are configurable
>on a per port basis.
>This patch provides a mechanism to configure switch ports by adding
>an NDO for setting specific values to specific attributes.
>There will be a separate patch that extends iproute2 to call the
>new NDO.
What are these attributes? Can you give some examples. I'm asking
because there is a plan to pass generic attributes to switch ports
replacing current specific ndo_switch_port_stp_update. In this case,
bridge is setting that attribute.
Is there need to set something directly from userspace or does it make
rather sense to use involved bridge/ovs/bond ? I think that both will be
needed.
>
>Signed-off-by: Marco Varlese <marco.varlese@intel.com>
>---
> include/linux/netdevice.h | 5 +++++
> include/uapi/linux/if_link.h | 1 +
> net/core/rtnetlink.c | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 39 insertions(+)
>
>diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>index c31f74d..4881c7b 100644
>--- a/include/linux/netdevice.h
>+++ b/include/linux/netdevice.h
>@@ -1027,6 +1027,9 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
> * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
> * Called to notify switch device port of bridge port STP
> * state change.
>+ * int (*ndo_switch_port_set_cfg)(struct net_device *dev,
>+ * u32 attr, u64 value);
>+ * Called to set specific switch ports attributes.
> */
> struct net_device_ops {
> int (*ndo_init)(struct net_device *dev);
>@@ -1185,6 +1188,8 @@ struct net_device_ops {
> struct netdev_phys_item_id *psid);
> int (*ndo_switch_port_stp_update)(struct net_device *dev,
> u8 state);
>+ int (*ndo_switch_port_set_cfg)(struct net_device *dev,
>+ u32 attr, u64 value);
> #endif
> };
>
>diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>index f7d0d2d..b35c314 100644
>--- a/include/uapi/linux/if_link.h
>+++ b/include/uapi/linux/if_link.h
>@@ -146,6 +146,7 @@ enum {
> IFLA_PHYS_PORT_ID,
> IFLA_CARRIER_CHANGES,
> IFLA_PHYS_SWITCH_ID,
>+ IFLA_SWITCH_PORT_CFG,
> __IFLA_MAX
> };
>
>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>index eaa057f..e1be9ca 100644
>--- a/net/core/rtnetlink.c
>+++ b/net/core/rtnetlink.c
>@@ -1389,6 +1389,25 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
> return 0;
> }
>
I believe that it would be better to move the code below to
net/switchdev/switchdev.c
>+#ifdef CONFIG_NET_SWITCHDEV
>+static int do_setswcfg(struct net_device *dev, struct nlattr *attr)
>+{
>+ int rem, err = -EINVAL;
>+ struct nlattr *v;
>+ const struct net_device_ops *ops = dev->netdev_ops;
>+
>+ nla_for_each_nested(v, attr, rem) {
>+ u32 op = nla_type(v);
>+ u64 value = nla_get_u64(v);
>+
>+ err = ops->ndo_switch_port_set_cfg(dev, op, value);
>+ if (err)
>+ break;
>+ }
>+ return err;
>+}
>+#endif
>+
> static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
> {
> int rem, err = -EINVAL;
>@@ -1740,6 +1759,20 @@ static int do_setlink(const struct sk_buff *skb,
> status |= DO_SETLINK_NOTIFY;
> }
> }
>+#ifdef CONFIG_NET_SWITCHDEV
>+ if (tb[IFLA_SWITCH_PORT_CFG]) {
>+ err = -EOPNOTSUPP;
>+ if (!ops->ndo_switch_port_set_cfg)
>+ goto errout;
>+ if (!ops->ndo_switch_parent_id_get)
>+ goto errout;
>+ err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
>+ if (err < 0)
>+ goto errout;
>+
>+ status |= DO_SETLINK_NOTIFY;
>+ }
>+#endif
> err = 0;
>
> errout:
>--
>1.8.5.3
>
^ permalink raw reply
* Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver
From: David Miller @ 2014-12-10 17:02 UTC (permalink / raw)
To: arnd
Cc: linux-arm-kernel, mark.rutland, devicetree, f.fainelli, linux,
eric.dumazet, sergei.shtylyov, netdev, agraf, xuwei5,
David.Laight, dingtianhong, zhangfei.gao
In-Reply-To: <34612839.hAkXUcbKUQ@wuerfel>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 10 Dec 2014 17:36:46 +0100
> Or is there any better alternative for broken hardware that lacks
> a TX-complete interrupt?
The only option is an hrtimer or similar.
^ permalink raw reply
* Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: John Fastabend @ 2014-12-10 17:03 UTC (permalink / raw)
To: Jiri Pirko
Cc: Varlese, Marco, netdev@vger.kernel.org,
stephen@networkplumber.org, Fastabend, John R,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20141210165018.GG1863@nanopsycho.orion>
On 12/10/2014 08:50 AM, Jiri Pirko wrote:
> Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com wrote:
>> From: Marco Varlese <marco.varlese@intel.com>
>>
>> Switch hardware offers a list of attributes that are configurable
>> on a per port basis.
>> This patch provides a mechanism to configure switch ports by adding
>> an NDO for setting specific values to specific attributes.
>> There will be a separate patch that extends iproute2 to call the
>> new NDO.
>
>
> What are these attributes? Can you give some examples. I'm asking
> because there is a plan to pass generic attributes to switch ports
> replacing current specific ndo_switch_port_stp_update. In this case,
> bridge is setting that attribute.
>
> Is there need to set something directly from userspace or does it make
> rather sense to use involved bridge/ovs/bond ? I think that both will be
> needed.
+1
I think for many attributes it would be best to have both. The in
kernel callers and netlink userspace can use the same driver ndo_ops.
But then we don't _require_ any specific bridge/ovs/etc module. And we
may have some attributes that are not specific to any existing software
module. I'm guessing Marco has some examples of these.
[...]
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH 1/6] net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag
From: Alexander Duyck @ 2014-12-10 17:06 UTC (permalink / raw)
To: Eric Dumazet, Alexander Duyck; +Cc: netdev, ast, davem, brouer
In-Reply-To: <1418227328.27198.25.camel@edumazet-glaptop2.roam.corp.google.com>
On 12/10/2014 08:02 AM, Eric Dumazet wrote:
> On Tue, 2014-12-09 at 19:40 -0800, Alexander Duyck wrote:
>
>> I also took the opportunity to refactor the core bits that were placed in
>> __alloc_page_frag. First I updated the allocation to do either a 32K
>> allocation or an order 0 page. This is based on the changes in commmit
>> d9b2938aa where it was found that latencies could be reduced in case of
>> failures.
>
> GFP_KERNEL and GFP_ATOMIC allocation constraints are quite different.
>
> I have no idea how expensive it is to attempt order-3, order-2, order-1
> allocations with GFP_ATOMIC.
The most likely case is the successful first allocation so I didn't see
much point in trying to optimize for the failure cases. I personally
prefer to see a fast failure rather than one that is dragged out over
several failed allocation attempts. In addition I can get away with
several optimization tricks that I cannot with the loop.
> I did an interesting experiment on mlx4 driver, allocating the pages
> needed to store the fragments, using a small layer before the
> alloc_page() that is normally used :
>
> - Attempt order-9 allocations, and use split_page() to give the
> individual pages.
>
> Boost in performance is 10% on TCP bulk receive, because of less TLB
> misses.
>
> With huge amount of memory these days, alloc_page() tend to give pages
> spread all over memory, with poor TLB locality.
>
> With this strategy, a 1024 RX ring is backed by 2 huge pages only.
That is an interesting idea. I wonder if there would be a similar
benefit for small packets. If nothing else I might try a few
experiments with ixgbe to see if I can take advantage of something similar.
- Alex
^ permalink raw reply
* atomic operations bottleneck in the IPv6 stack
From: cristian.bercaru @ 2014-12-10 16:56 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: R89243@freescale.com, Madalin-Cristian Bucur,
Razvan.Ungureanu@freescale.com
Hello!
I am running IPv6 forwarding cases and I get worse performance with 24 cores than with 16 cores.
Test scenario:
10G --->[T4240]---> 10G
- platform: Freescale T4240, powerpc, 24 x e6500 64-bit cores (I can disable 8 of them from uboot)
- input type: raw IPv6 78-byte packets
- input rate: 10Gbps
- forwarding/output rate: 16 cores - 3.3 Gbps; 24 cores - 2.4 Gbps
Doing a perf with "record -C 1 -c 10000000 -a sleep 120" record I observe
- on 16 cores
# Overhead Command Shared Object Symbol
19.59% ksoftirqd/1 [kernel.kallsyms] [k] .ip6_pol_route
18.07% ksoftirqd/1 [kernel.kallsyms] [k] .dst_release
5.09% ksoftirqd/1 [kernel.kallsyms] [k] .__netif_receive_skb_core
- on 24 cores
34.98% ksoftirqd/1 [kernel.kallsyms] [k] .ip6_pol_route
31.86% ksoftirqd/1 [kernel.kallsyms] [k] .dst_release
3.76% ksoftirqd/1 [kernel.kallsyms] [k] .ip6_finish_output2
2.72% ksoftirqd/1 [kernel.kallsyms] [k] .__netif_receive_skb_core
I de-inlined 'atomic_dec_return' and 'atomic_inc' that are used by 'ip6_pol_route' and 'dst_release' and I get
- on 16 cores
17.26% ksoftirqd/1 [kernel.kallsyms] [k] .atomic_dec_return_noinline
13.45% ksoftirqd/1 [kernel.kallsyms] [k] .atomic_inc_noinline
5.53% ksoftirqd/1 [kernel.kallsyms] [k] .ip6_pol_route
5.02% ksoftirqd/1 [kernel.kallsyms] [k] .__netif_receive_skb_core
- on 24 cores
32.45% ksoftirqd/1 [kernel.kallsyms] [k] .atomic_dec_return_noinline
30.56% ksoftirqd/1 [kernel.kallsyms] [k] .atomic_inc_noinline
4.71% ksoftirqd/1 [kernel.kallsyms] [k] .ip6_pol_route
3.57% ksoftirqd/1 [kernel.kallsyms] [k] .ip6_finish_output2
It seems to me that the atomic operations on the IPv6 forwarding path are a bottleneck and they are not scalable with the number of cores. Am I right? What improvements can be brought to the IPv6 kernel code to make it less dependent of atomic operations/variables?
Thank you,
Cristian Bercaru
^ permalink raw reply
* Re: [net-next PATCH 1/6] net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag
From: Eric Dumazet @ 2014-12-10 17:13 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Alexander Duyck, netdev, ast, davem, brouer
In-Reply-To: <54887DB0.7040903@gmail.com>
On Wed, 2014-12-10 at 09:06 -0800, Alexander Duyck wrote:
> That is an interesting idea. I wonder if there would be a similar
> benefit for small packets. If nothing else I might try a few
> experiments with ixgbe to see if I can take advantage of something similar.
I was planning to submit a core infrastructure when net-next reopens, a
simple layer to use instead of alloc_page(), and immediately usable in
Intel drivers.
^ permalink raw reply
* Re: atomic operations bottleneck in the IPv6 stack
From: Hannes Frederic Sowa @ 2014-12-10 17:16 UTC (permalink / raw)
To: cristian.bercaru@freescale.com
Cc: netdev@vger.kernel.org, R89243@freescale.com,
Madalin-Cristian Bucur, Razvan.Ungureanu@freescale.com
In-Reply-To: <SN2PR03MB079DA7799199CD98C52B5389E620@SN2PR03MB079.namprd03.prod.outlook.com>
On Mi, 2014-12-10 at 16:56 +0000, cristian.bercaru@freescale.com wrote:
>
> It seems to me that the atomic operations on the IPv6 forwarding path
> are a bottleneck and they are not scalable with the number of cores.
> Am I right? What improvements can be brought to the IPv6 kernel code
> to make it less dependent of atomic operations/variables?
For a starter, something like the following commit:
commit d26b3a7c4b3b26319f18bb645de93eba8f4bdcd5
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Jul 31 05:45:30 2012 +0000
ipv4: percpu nh_rth_output cache
Bye,
Hannes
^ permalink raw reply
* Re: [net-next PATCH 1/6] net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag
From: Alexander Duyck @ 2014-12-10 17:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev, ast, davem, brouer
In-Reply-To: <1418231580.27198.30.camel@edumazet-glaptop2.roam.corp.google.com>
On 12/10/2014 09:13 AM, Eric Dumazet wrote:
> On Wed, 2014-12-10 at 09:06 -0800, Alexander Duyck wrote:
>
>> That is an interesting idea. I wonder if there would be a similar
>> benefit for small packets. If nothing else I might try a few
>> experiments with ixgbe to see if I can take advantage of something similar.
> I was planning to submit a core infrastructure when net-next reopens, a
> simple layer to use instead of alloc_page(), and immediately usable in
> Intel drivers.
Sound good. I look forward to it.
^ permalink raw reply
* Re: am335x: cpsw: interrupt failure
From: Felipe Balbi @ 2014-12-10 17:17 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Felipe Balbi, netdev, N, Mugunthan V
In-Reply-To: <CAGm1_ksNuO75QfgaDUpOe525xDkPhby-z8T=MX3DHdB-LVcR8g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3078 bytes --]
Hi,
On Fri, Dec 05, 2014 at 11:03:44AM +0100, Yegor Yefremov wrote:
> On Thu, Dec 4, 2014 at 5:56 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Thu, Dec 04, 2014 at 05:41:38PM +0100, Yegor Yefremov wrote:
> >> I have following problem. My systems reboots at high network load
> >> after this commit (found via git bissect):
> >>
> >> commit 55601c9f24670ba926ebdd4d712ac3b177232330
> >> Author: Felipe Balbi <balbi@ti.com>
> >> Date: Mon Sep 8 17:54:58 2014 -0700
> >>
> >> arm: omap: intc: switch over to linear irq domain
> >>
> >> now that we don't need to support legacy board-files,
> >> we can completely switch over to a linear irq domain
> >> and make use of irq_alloc_domain_generic_chips() to
> >> allocate all generic irq chips for us.
> >>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> Signed-off-by: Tony Lindgren <tony@atomide.com>
> >>
> >> and I get following error messages:
> >>
> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
> >
> > irq 0 ? Weird, that's not a valid IRQ.
> >
> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
> >> ->action(): (null)
> >> IRQ_NOPROBE set
> >> IRQ_NOREQUEST set
> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
> >> ->action(): (null)
> >> IRQ_NOPROBE set
> >> IRQ_NOREQUEST set
> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
> >> ->action(): (null)
> >> IRQ_NOPROBE set
> >> IRQ_NOREQUEST set
> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
> >> ->action(): (null)
> >>
> >> My system: am335x with fast ethernet on the first slave and gigabit
> >> Ethernet on second CPSW slave. This issue occurs, when I ran nuttcp
> >> with default settings.
> >>
> >> With commit above I can at least see these messages, but 3.18-rc7 for
> >> example reboots without any messages.
> >>
> >> Any idea?
> >
> > if you take v3.18-rc7 and just revert that commit, does the problem go
> > away ?
>
> git revert failed as the driver has more changes meanwhile or I'm
> missing some params. I've tried to force the driver to use legacy
> routines, but then I don't get pass U-Boot's "Starting kernel ..." See
> attached patch.
>
> Compiler used:
>
> Linux version 3.18.0-rc7 (...) (gcc version 4.8.3 20140320
> (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #309 SMP Fri Dec 5
> 10:59:38 CET 2014
>
> Btw, what am335x based hardware do you have? I can run tests on both
> BBB and am335x-evmsk.
coming back to this. I have BBB only. Can you provide some extra
information on how I can trigger this problem here ?
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
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