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;
>>
next prev parent reply other threads:[~2016-09-12 3:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 21:29 [net-next PATCH v2 1/2] e1000: add initial XDP support John Fastabend
2016-09-09 21:29 ` [net-next PATCH v2 2/2] e1000: bundle xdp xmit routines John Fastabend
2016-09-09 23:37 ` John Fastabend
2016-09-09 23:44 ` Tom Herbert
2016-09-10 0:01 ` John Fastabend
2016-09-10 1:04 ` Tom Herbert
2016-09-10 1:12 ` John Fastabend
2016-09-10 1:19 ` Tom Herbert
2016-09-10 1:40 ` Alexei Starovoitov
2016-09-10 3:12 ` Tom Herbert
2016-09-10 3:26 ` John Fastabend
2016-09-10 4:13 ` Tom Herbert
2016-09-12 3:15 ` John Fastabend
2016-09-12 4:12 ` Alexei Starovoitov
2016-09-10 3:56 ` Alexei Starovoitov
2016-09-12 11:56 ` Jesper Dangaard Brouer
2016-09-10 15:36 ` Tom Herbert
2016-09-12 3:07 ` John Fastabend [this message]
2016-09-12 12:17 ` Jesper Dangaard Brouer
2016-09-12 18:11 ` John Fastabend
2016-09-09 22:04 ` [net-next PATCH v2 1/2] e1000: add initial XDP support Eric Dumazet
2016-09-09 23:33 ` John Fastabend
2016-09-21 4:26 ` zhuyj
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=alexei.starovoitov@gmail.com \
--cc=bblanco@plumgrid.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.com \
--cc=u9012063@gmail.com \
--cc=xiyou.wangcong@gmail.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;
as well as URLs for NNTP newsgroup(s).