All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [net-next PATCH v2 2/2] e1000: bundle xdp xmit routines
Date: Sun, 11 Sep 2016 20:07:18 -0700	[thread overview]
Message-ID: <57D61BE6.2080002@gmail.com> (raw)
In-Reply-To: <CALx6S34+Mgb173vReYt=yPOztcFhVU9rRZyodVc56toXP1OiHQ@mail.gmail.com>

On 16-09-10 08:36 AM, Tom Herbert wrote:
> On Fri, Sep 9, 2016 at 2:29 PM, John Fastabend <john.fastabend@gmail.com> wrote:
>> e1000 supports a single TX queue so it is being shared with the stack
>> when XDP runs XDP_TX action. This requires taking the xmit lock to
>> ensure we don't corrupt the tx ring. To avoid taking and dropping the
>> lock per packet this patch adds a bundling implementation to submit
>> a bundle of packets to the xmit routine.
>>
>> I tested this patch running e1000 in a VM using KVM over a tap
>> device using pktgen to generate traffic along with 'ping -f -l 100'.
>>
>> Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---

[...]

>> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> index 91d5c87..b985271 100644
>> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> @@ -1738,10 +1738,18 @@ static int e1000_setup_rx_resources(struct e1000_adapter *adapter,
>>         struct pci_dev *pdev = adapter->pdev;
>>         int size, desc_len;
>>
>> +       size = sizeof(struct e1000_rx_buffer_bundle) *
>> +                       E1000_XDP_XMIT_BUNDLE_MAX;
>> +       rxdr->xdp_buffer = vzalloc(size);
>> +       if (!rxdr->xdp_buffer)
>> +               return -ENOMEM;
>> +
>>         size = sizeof(struct e1000_rx_buffer) * rxdr->count;
>>         rxdr->buffer_info = vzalloc(size);
>> -       if (!rxdr->buffer_info)
>> +       if (!rxdr->buffer_info) {
>> +               vfree(rxdr->xdp_buffer);
> 
> This could be deferred until an XDP program is added.

Yep that would be best to avoid overhead in the normal non-XDP case.
Also I'll move the xdp prog pointer into the rx ring per Jespers comment
that I missed in this rev.

[...]

>> +
>> +static void e1000_xdp_xmit_bundle(struct e1000_rx_buffer_bundle *buffer_info,
>> +                                 struct net_device *netdev,
>> +                                 struct e1000_adapter *adapter)
>> +{
>> +       struct netdev_queue *txq = netdev_get_tx_queue(netdev, 0);
>> +       struct e1000_tx_ring *tx_ring = adapter->tx_ring;
>> +       struct e1000_hw *hw = &adapter->hw;
>> +       int i = 0;
>> +
>>         /* e1000 only support a single txq at the moment so the queue is being
>>          * shared with stack. To support this requires locking to ensure the
>>          * stack and XDP are not running at the same time. Devices with
>>          * multiple queues should allocate a separate queue space.
>> +        *
>> +        * To amortize the locking cost e1000 bundles the xmits and sends as
>> +        * many as possible until either running out of descriptors or failing.
> 
> Up to E1000_XDP_XMIT_BUNDLE_MAX  at least...

Yep will fix comment.

[...]

>>
>>                 /* use prefetched values */
>> @@ -4498,8 +4536,11 @@ next_desc:
>>         rx_ring->next_to_clean = i;
>>
>>         cleaned_count = E1000_DESC_UNUSED(rx_ring);
>> -       if (cleaned_count)
>> +       if (cleaned_count) {
>> +               if (xdp_xmit)
>> +                       e1000_xdp_xmit_bundle(xdp_bundle, netdev, adapter);
>>                 adapter->alloc_rx_buf(adapter, rx_ring, cleaned_count);
>> +       }
> 
> Looks good for XDP path. Is this something we can abstract out into a
> library for use by other drivers?
> 

I'm not really sure it can be abstracted much its a bit intertwined with
the normal rx receive path. But it should probably be a pattern that
gets copied so we avoid unnecessary tx work.

> 
>>
>>         adapter->total_rx_packets += total_rx_packets;
>>         adapter->total_rx_bytes += total_rx_bytes;
>>


WARNING: multiple messages have this Message-ID (diff)
From: John Fastabend <john.fastabend@gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Brenden Blanco <bblanco@plumgrid.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
	William Tu <u9012063@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [net-next PATCH v2 2/2] e1000: bundle xdp xmit routines
Date: Sun, 11 Sep 2016 20:07:18 -0700	[thread overview]
Message-ID: <57D61BE6.2080002@gmail.com> (raw)
In-Reply-To: <CALx6S34+Mgb173vReYt=yPOztcFhVU9rRZyodVc56toXP1OiHQ@mail.gmail.com>

On 16-09-10 08:36 AM, Tom Herbert wrote:
> On Fri, Sep 9, 2016 at 2:29 PM, John Fastabend <john.fastabend@gmail.com> wrote:
>> e1000 supports a single TX queue so it is being shared with the stack
>> when XDP runs XDP_TX action. This requires taking the xmit lock to
>> ensure we don't corrupt the tx ring. To avoid taking and dropping the
>> lock per packet this patch adds a bundling implementation to submit
>> a bundle of packets to the xmit routine.
>>
>> I tested this patch running e1000 in a VM using KVM over a tap
>> device using pktgen to generate traffic along with 'ping -f -l 100'.
>>
>> Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---

[...]

>> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> index 91d5c87..b985271 100644
>> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> @@ -1738,10 +1738,18 @@ static int e1000_setup_rx_resources(struct e1000_adapter *adapter,
>>         struct pci_dev *pdev = adapter->pdev;
>>         int size, desc_len;
>>
>> +       size = sizeof(struct e1000_rx_buffer_bundle) *
>> +                       E1000_XDP_XMIT_BUNDLE_MAX;
>> +       rxdr->xdp_buffer = vzalloc(size);
>> +       if (!rxdr->xdp_buffer)
>> +               return -ENOMEM;
>> +
>>         size = sizeof(struct e1000_rx_buffer) * rxdr->count;
>>         rxdr->buffer_info = vzalloc(size);
>> -       if (!rxdr->buffer_info)
>> +       if (!rxdr->buffer_info) {
>> +               vfree(rxdr->xdp_buffer);
> 
> This could be deferred until an XDP program is added.

Yep that would be best to avoid overhead in the normal non-XDP case.
Also I'll move the xdp prog pointer into the rx ring per Jespers comment
that I missed in this rev.

[...]

>> +
>> +static void e1000_xdp_xmit_bundle(struct e1000_rx_buffer_bundle *buffer_info,
>> +                                 struct net_device *netdev,
>> +                                 struct e1000_adapter *adapter)
>> +{
>> +       struct netdev_queue *txq = netdev_get_tx_queue(netdev, 0);
>> +       struct e1000_tx_ring *tx_ring = adapter->tx_ring;
>> +       struct e1000_hw *hw = &adapter->hw;
>> +       int i = 0;
>> +
>>         /* e1000 only support a single txq at the moment so the queue is being
>>          * shared with stack. To support this requires locking to ensure the
>>          * stack and XDP are not running at the same time. Devices with
>>          * multiple queues should allocate a separate queue space.
>> +        *
>> +        * To amortize the locking cost e1000 bundles the xmits and sends as
>> +        * many as possible until either running out of descriptors or failing.
> 
> Up to E1000_XDP_XMIT_BUNDLE_MAX  at least...

Yep will fix comment.

[...]

>>
>>                 /* use prefetched values */
>> @@ -4498,8 +4536,11 @@ next_desc:
>>         rx_ring->next_to_clean = i;
>>
>>         cleaned_count = E1000_DESC_UNUSED(rx_ring);
>> -       if (cleaned_count)
>> +       if (cleaned_count) {
>> +               if (xdp_xmit)
>> +                       e1000_xdp_xmit_bundle(xdp_bundle, netdev, adapter);
>>                 adapter->alloc_rx_buf(adapter, rx_ring, cleaned_count);
>> +       }
> 
> Looks good for XDP path. Is this something we can abstract out into a
> library for use by other drivers?
> 

I'm not really sure it can be abstracted much its a bit intertwined with
the normal rx receive path. But it should probably be a pattern that
gets copied so we avoid unnecessary tx work.

> 
>>
>>         adapter->total_rx_packets += total_rx_packets;
>>         adapter->total_rx_bytes += total_rx_bytes;
>>

  reply	other threads:[~2016-09-12  3:07 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 21:29 [Intel-wired-lan] [net-next PATCH v2 1/2] e1000: add initial XDP support John Fastabend
2016-09-09 21:29 ` John Fastabend
2016-09-09 21:29 ` [Intel-wired-lan] [net-next PATCH v2 2/2] e1000: bundle xdp xmit routines John Fastabend
2016-09-09 21:29   ` John Fastabend
2016-09-09 23:37   ` [Intel-wired-lan] " John Fastabend
2016-09-09 23:37     ` John Fastabend
2016-09-09 23:44   ` [Intel-wired-lan] " Tom Herbert
2016-09-09 23:44     ` Tom Herbert
2016-09-10  0:01     ` [Intel-wired-lan] " John Fastabend
2016-09-10  0:01       ` John Fastabend
2016-09-10  1:04       ` [Intel-wired-lan] " Tom Herbert
2016-09-10  1:04         ` Tom Herbert
2016-09-10  1:12         ` [Intel-wired-lan] " John Fastabend
2016-09-10  1:12           ` John Fastabend
2016-09-10  1:19           ` [Intel-wired-lan] " Tom Herbert
2016-09-10  1:19             ` Tom Herbert
2016-09-10  1:40             ` [Intel-wired-lan] " Alexei Starovoitov
2016-09-10  1:40               ` Alexei Starovoitov
2016-09-10  3:12               ` [Intel-wired-lan] " Tom Herbert
2016-09-10  3:12                 ` Tom Herbert
2016-09-10  3:26                 ` [Intel-wired-lan] " John Fastabend
2016-09-10  3:26                   ` John Fastabend
2016-09-10  4:13                   ` [Intel-wired-lan] " Tom Herbert
2016-09-10  4:13                     ` Tom Herbert
2016-09-12  3:15                     ` [Intel-wired-lan] " John Fastabend
2016-09-12  3:15                       ` John Fastabend
2016-09-12  4:12                       ` [Intel-wired-lan] " Alexei Starovoitov
2016-09-12  4:12                         ` Alexei Starovoitov
2016-09-10  3:56                 ` [Intel-wired-lan] " Alexei Starovoitov
2016-09-10  3:56                   ` Alexei Starovoitov
2016-09-12 11:56             ` [Intel-wired-lan] " Jesper Dangaard Brouer
2016-09-12 11:56               ` Jesper Dangaard Brouer
2016-09-10 15:36   ` [Intel-wired-lan] " Tom Herbert
2016-09-10 15:36     ` Tom Herbert
2016-09-12  3:07     ` John Fastabend [this message]
2016-09-12  3:07       ` John Fastabend
2016-09-12 12:17   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2016-09-12 12:17     ` Jesper Dangaard Brouer
2016-09-12 18:11     ` [Intel-wired-lan] " John Fastabend
2016-09-12 18:11       ` John Fastabend
2016-09-09 22:04 ` [Intel-wired-lan] [net-next PATCH v2 1/2] e1000: add initial XDP support Eric Dumazet
2016-09-09 22:04   ` Eric Dumazet
2016-09-09 23:33   ` [Intel-wired-lan] " John Fastabend
2016-09-09 23:33     ` John Fastabend
2016-09-21  4:26 ` [Intel-wired-lan] " zhuyj
2016-09-21  4:26   ` zhuyj
2016-09-21  4:30   ` [Intel-wired-lan] " John Fastabend
2016-09-21  4:30     ` John Fastabend

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=57D61BE6.2080002@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=intel-wired-lan@osuosl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.