netdev - Re: [RFC 9/9] bnxt_en: add support for software adaptive interrupt moderation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACKFLikxoWJ7T-4ADmWW7oDs-XtNrw=9RgMs6CaR1Rg06M2x4Q@mail.gmail.com>
Date:   Mon, 6 Nov 2017 13:26:44 -0800
From:   Michael Chan <michael.chan@...adcom.com>
To:     Andy Gospodarek <andy@...yhouse.net>
Cc:     Netdev <netdev@...r.kernel.org>,
        "michael.chan@...adcom.com" <mchan@...adcom.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Andy Gospodarek <gospo@...adcom.com>
Subject: Re: [RFC 9/9] bnxt_en: add support for software adaptive interrupt moderation

On Sun, Nov 5, 2017 at 9:44 PM, Andy Gospodarek <andy@...yhouse.net> wrote:
> From: Andy Gospodarek <gospo@...adcom.com>
>
> This implements the changes needed for the bnxt_en driver to add support
> for adaptive interrupt moderation per ring.
>
> This does add additional counters in the receive path, but testing shows
> that any additional instructions are offset by throughput gain when the
> default configuration is for low latency.
>
> Signed-off-by: Andy Gospodarek <gospo@...adcom.com>
> ---
>  drivers/net/ethernet/broadcom/bnxt/Makefile       |  2 +-
>  drivers/net/ethernet/broadcom/bnxt/bnxt.c         | 51 +++++++++++++++++++++++
>  drivers/net/ethernet/broadcom/bnxt/bnxt.h         | 34 ++++++++++-----
>  drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c |  7 ++++
>  drivers/net/ethernet/broadcom/bnxt/bnxt_rx_am.c   | 32 ++++++++++++++
>  5 files changed, 114 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/net/ethernet/broadcom/bnxt/bnxt_rx_am.c
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/Makefile b/drivers/net/ethernet/broadcom/bnxt/Makefile
> index 59c8ec9..1b0c78c 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/Makefile
> +++ b/drivers/net/ethernet/broadcom/bnxt/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_BNXT) += bnxt_en.o
>
> -bnxt_en-y := bnxt.o bnxt_sriov.o bnxt_ethtool.o bnxt_dcb.o bnxt_ulp.o bnxt_xdp.o bnxt_vfr.o bnxt_devlink.o
> +bnxt_en-y := bnxt.o bnxt_sriov.o bnxt_ethtool.o bnxt_dcb.o bnxt_ulp.o bnxt_xdp.o bnxt_vfr.o bnxt_devlink.o bnxt_rx_am.o
>  bnxt_en-$(CONFIG_BNXT_FLOWER_OFFLOAD) += bnxt_tc.o
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index 4e3d569..e1110d9 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -1482,6 +1482,7 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct bnxt_napi *bnapi, u32 *raw_cons,
>         u32 tmp_raw_cons = *raw_cons;
>         u16 cfa_code, cons, prod, cp_cons = RING_CMP(tmp_raw_cons);
>         struct bnxt_sw_rx_bd *rx_buf;
> +       unsigned int pkts = 0;
>         unsigned int len;
>         u8 *data_ptr, agg_bufs, cmp_type;
>         dma_addr_t dma_addr;
> @@ -1522,6 +1523,8 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct bnxt_napi *bnapi, u32 *raw_cons,
>
>                 rc = -ENOMEM;
>                 if (likely(skb)) {
> +                       struct skb_shared_info *shinfo = skb_shinfo(skb);
> +                       pkts = shinfo->nr_frags;
>                         bnxt_deliver_skb(bp, bnapi, skb);
>                         rc = 1;
>                 }
> @@ -1645,6 +1648,8 @@ static int bnxt_rx_pkt(struct bnxt *bp, struct bnxt_napi *bnapi, u32 *raw_cons,
>         rxr->rx_next_cons = NEXT_RX(cons);
>
>  next_rx_no_prod:
> +       cpr->rx_packets += pkts ? : 1;
> +       cpr->rx_bytes += len;

These counters are in the RX fast path, including the XDP fast path.
If we are handling tens of millions of packets per second, every
packet has to incur the cost of these counters.

It will be much nicer if we can use the hardware counters instead.