From: Neil Horman <nhorman@redhat.com>
To: Xue Chaojing <xuechaojing@huawei.com>
Cc: davem@davemloft.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, wulike1@huawei.com, chiqijun@huawei.com,
fy.wang@huawei.com, tony.qu@huawei.com, luoshaokai@huawei.com
Subject: Re: [PATCH 1/1] net-next/hinic:optmize rx refill buffer mechanism
Date: Thu, 13 Dec 2018 09:31:21 -0500 [thread overview]
Message-ID: <20181213143121.GA5562@hmswarspite.think-freely.org> (raw)
In-Reply-To: <20181212174023.20416-1-xuechaojing@huawei.com>
On Wed, Dec 12, 2018 at 05:40:23PM +0000, Xue Chaojing wrote:
> There is no need to schedule a different tasklet for refill,
> This patch remove it.
>
> Suggested-by: Neil Horman <nhorman@redhat.com>
> Signed-off-by: Xue Chaojing <xuechaojing@huawei.com>
> ---
> drivers/net/ethernet/huawei/hinic/hinic_rx.c | 23 +++++---------------
> drivers/net/ethernet/huawei/hinic/hinic_rx.h | 2 --
> 2 files changed, 5 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.c b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
> index f86f2e693224..0098b206e7e9 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
> @@ -43,6 +43,7 @@
> #define RX_IRQ_NO_LLI_TIMER 0
> #define RX_IRQ_NO_CREDIT 0
> #define RX_IRQ_NO_RESEND_TIMER 0
> +#define HINIC_RX_BUFFER_WRITE 16
>
> /**
> * hinic_rxq_clean_stats - Clean the statistics of specific queue
> @@ -229,7 +230,6 @@ static int rx_alloc_pkts(struct hinic_rxq *rxq)
> wmb(); /* write all the wqes before update PI */
>
> hinic_rq_update(rxq->rq, prod_idx);
> - tasklet_schedule(&rxq->rx_task);
> }
>
> return i;
> @@ -258,17 +258,6 @@ static void free_all_rx_skbs(struct hinic_rxq *rxq)
> }
> }
>
> -/**
> - * rx_alloc_task - tasklet for queue allocation
> - * @data: rx queue
> - **/
> -static void rx_alloc_task(unsigned long data)
> -{
> - struct hinic_rxq *rxq = (struct hinic_rxq *)data;
> -
> - (void)rx_alloc_pkts(rxq);
> -}
> -
> /**
> * rx_recv_jumbo_pkt - Rx handler for jumbo pkt
> * @rxq: rx queue
> @@ -333,6 +322,7 @@ static int rxq_recv(struct hinic_rxq *rxq, int budget)
> struct hinic_qp *qp = container_of(rxq->rq, struct hinic_qp, rq);
> u64 pkt_len = 0, rx_bytes = 0;
> struct hinic_rq_wqe *rq_wqe;
> + unsigned int free_wqebbs;
> int num_wqes, pkts = 0;
> struct hinic_sge sge;
> struct sk_buff *skb;
> @@ -376,8 +366,9 @@ static int rxq_recv(struct hinic_rxq *rxq, int budget)
> rx_bytes += pkt_len;
> }
>
> - if (pkts)
> - tasklet_schedule(&rxq->rx_task); /* rx_alloc_pkts */
> + free_wqebbs = hinic_get_rq_free_wqebbs(rxq->rq);
> + if (free_wqebbs > HINIC_RX_BUFFER_WRITE)
> + rx_alloc_pkts(rxq);
>
> u64_stats_update_begin(&rxq->rxq_stats.syncp);
> rxq->rxq_stats.pkts += pkts;
> @@ -494,8 +485,6 @@ int hinic_init_rxq(struct hinic_rxq *rxq, struct hinic_rq *rq,
>
> sprintf(rxq->irq_name, "hinic_rxq%d", qp->q_id);
>
> - tasklet_init(&rxq->rx_task, rx_alloc_task, (unsigned long)rxq);
> -
> pkts = rx_alloc_pkts(rxq);
> if (!pkts) {
> err = -ENOMEM;
> @@ -512,7 +501,6 @@ int hinic_init_rxq(struct hinic_rxq *rxq, struct hinic_rq *rq,
>
> err_req_rx_irq:
> err_rx_pkts:
> - tasklet_kill(&rxq->rx_task);
> free_all_rx_skbs(rxq);
> devm_kfree(&netdev->dev, rxq->irq_name);
> return err;
> @@ -528,7 +516,6 @@ void hinic_clean_rxq(struct hinic_rxq *rxq)
>
> rx_free_irq(rxq);
>
> - tasklet_kill(&rxq->rx_task);
> free_all_rx_skbs(rxq);
> devm_kfree(&netdev->dev, rxq->irq_name);
> }
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.h b/drivers/net/ethernet/huawei/hinic/hinic_rx.h
> index ab3fabab91b2..f8ed3fa6c8ee 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_rx.h
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.h
> @@ -42,8 +42,6 @@ struct hinic_rxq {
>
> char *irq_name;
>
> - struct tasklet_struct rx_task;
> -
> struct napi_struct napi;
> };
>
> --
> 2.17.1
>
I like that you're getting rid of the extra tasklet, but the other part of this
is properly refilling your rx ring. The way you have this coded, you always
blindly just receive the incomming frame, even if your refill operation fails.
If you get a long enough period in which you are memory constrained, you will
wind up with an empty rx ring, which isn't good. With this patch, if your ring
becomes empty, then you will stop receiving frames (no buffers to put them in),
which in turn will prevent further attempts to refill the ring. The result is
effectively a hang in traffic reception that is only solveable by a NIC reset.
Common practice is to, for each skb that you intend to receive:
1) Allocate a replacement buffer/skb
2a) If allocation succedes, receive the buffer currently on the ring, and
replace it with the buffer from (1)
2b) If allocation fails, record a frame drop, mark the existing buffer as clean,
and move on
This process ensures that the ring never has any gaps in it, preventing the
above hang condition.
Neil
next prev parent reply other threads:[~2018-12-13 14:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-12 17:40 Xue Chaojing
2018-12-13 14:31 ` Neil Horman [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-12-16 22:32 Xue Chaojing
2018-12-17 17:02 ` Neil Horman
2018-12-17 19:13 ` David Miller
2018-12-09 19:14 Xue Chaojing
2018-12-15 19:31 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181213143121.GA5562@hmswarspite.think-freely.org \
--to=nhorman@redhat.com \
--cc=chiqijun@huawei.com \
--cc=davem@davemloft.net \
--cc=fy.wang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luoshaokai@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=tony.qu@huawei.com \
--cc=wulike1@huawei.com \
--cc=xuechaojing@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®