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: Mon, 12 Sep 2016 11:11:52 -0700	[thread overview]
Message-ID: <57D6EFE8.50707@gmail.com> (raw)
In-Reply-To: <20160912141755.365c169e@redhat.com>

On 16-09-12 05:17 AM, Jesper Dangaard Brouer wrote:
> On Fri, 09 Sep 2016 14:29:38 -0700
> 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>
> 
> Thank you for actually implementing this! :-)
> 

Yep no problem the effects are minimal on e1000 but should be
noticeable at 10/40/100gbps nics.

>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
> [...]


[...]

>> +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.
>>  	 */
>>  	HARD_TX_LOCK(netdev, txq, smp_processor_id());
>>  
>> -	tx_ring = adapter->tx_ring;
>> -
>> -	if (E1000_DESC_UNUSED(tx_ring) < 2) {
>> -		HARD_TX_UNLOCK(netdev, txq);
>> -		return;
>> +	for (; i < E1000_XDP_XMIT_BUNDLE_MAX && buffer_info[i].buffer; i++) {
>                                                                        ^^^
>> +		e1000_xmit_raw_frame(buffer_info[i].buffer,
>> +				     buffer_info[i].length,
>> +				     adapter, tx_ring);
>> +		buffer_info[i].buffer->rxbuf.page = NULL;
>> +		buffer_info[i].buffer = NULL;
>> +		buffer_info[i].length = 0;
>> +		i++;
>                 ^^^
> Looks like "i" is incremented twice, is that correct?
> 
>>  	}

Yep this and a couple other issues are resolved in v3 which I'll send
out in a moment.

Also in v3 I kept the program in the adapter structure. Moving it into
the ring structure made the code a bit uglier IMO. I agree with the
logic but practically only one program can exist for e1000.


WARNING: multiple messages have this Message-ID (diff)
From: John Fastabend <john.fastabend@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: bblanco@plumgrid.com, alexei.starovoitov@gmail.com,
	jeffrey.t.kirsher@intel.com, davem@davemloft.net,
	xiyou.wangcong@gmail.com, intel-wired-lan@lists.osuosl.org,
	u9012063@gmail.com, netdev@vger.kernel.org
Subject: Re: [net-next PATCH v2 2/2] e1000: bundle xdp xmit routines
Date: Mon, 12 Sep 2016 11:11:52 -0700	[thread overview]
Message-ID: <57D6EFE8.50707@gmail.com> (raw)
In-Reply-To: <20160912141755.365c169e@redhat.com>

On 16-09-12 05:17 AM, Jesper Dangaard Brouer wrote:
> On Fri, 09 Sep 2016 14:29:38 -0700
> 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>
> 
> Thank you for actually implementing this! :-)
> 

Yep no problem the effects are minimal on e1000 but should be
noticeable at 10/40/100gbps nics.

>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
> [...]


[...]

>> +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.
>>  	 */
>>  	HARD_TX_LOCK(netdev, txq, smp_processor_id());
>>  
>> -	tx_ring = adapter->tx_ring;
>> -
>> -	if (E1000_DESC_UNUSED(tx_ring) < 2) {
>> -		HARD_TX_UNLOCK(netdev, txq);
>> -		return;
>> +	for (; i < E1000_XDP_XMIT_BUNDLE_MAX && buffer_info[i].buffer; i++) {
>                                                                        ^^^
>> +		e1000_xmit_raw_frame(buffer_info[i].buffer,
>> +				     buffer_info[i].length,
>> +				     adapter, tx_ring);
>> +		buffer_info[i].buffer->rxbuf.page = NULL;
>> +		buffer_info[i].buffer = NULL;
>> +		buffer_info[i].length = 0;
>> +		i++;
>                 ^^^
> Looks like "i" is incremented twice, is that correct?
> 
>>  	}

Yep this and a couple other issues are resolved in v3 which I'll send
out in a moment.

Also in v3 I kept the program in the adapter structure. Moving it into
the ring structure made the code a bit uglier IMO. I agree with the
logic but practically only one program can exist for e1000.

  reply	other threads:[~2016-09-12 18:11 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     ` [Intel-wired-lan] " John Fastabend
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     ` John Fastabend [this message]
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=57D6EFE8.50707@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.