From: John Fastabend <john.fastabend@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: bblanco@plumgrid.com, alexei.starovoitov@gmail.com,
jeffrey.t.kirsher@intel.com, brouer@redhat.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 1/2] e1000: add initial XDP support
Date: Fri, 9 Sep 2016 16:33:10 -0700 [thread overview]
Message-ID: <57D346B6.3000204@gmail.com> (raw)
In-Reply-To: <1473458654.18970.69.camel@edumazet-glaptop3.roam.corp.google.com>
On 16-09-09 03:04 PM, Eric Dumazet wrote:
> On Fri, 2016-09-09 at 14:29 -0700, John Fastabend wrote:
>> From: Alexei Starovoitov <ast@fb.com>
>>
>
>
> So it looks like e1000_xmit_raw_frame() can return early,
> say if there is no available descriptor.
>
>> +static void e1000_xmit_raw_frame(struct e1000_rx_buffer *rx_buffer_info,
>> + unsigned int len,
>> + struct net_device *netdev,
>> + struct e1000_adapter *adapter)
>> +{
>> + struct netdev_queue *txq = netdev_get_tx_queue(netdev, 0);
>> + struct e1000_hw *hw = &adapter->hw;
>> + struct e1000_tx_ring *tx_ring;
>> +
>> + if (len > E1000_MAX_DATA_PER_TXD)
>> + return;
>> +
>> + /* 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.
>> + */
>> + 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;
>> + }
>> +
>> + e1000_tx_map_rxpage(tx_ring, rx_buffer_info, len);
>> + e1000_tx_queue(adapter, tx_ring, 0/*tx_flags*/, 1);
>> +
>> + writel(tx_ring->next_to_use, hw->hw_addr + tx_ring->tdt);
>> + mmiowb();
>> +
>> + HARD_TX_UNLOCK(netdev, txq);
>> +}
>> +
>> #define NUM_REGS 38 /* 1 based count */
>> static void e1000_regdump(struct e1000_adapter *adapter)
>> {
>> @@ -4142,6 +4247,19 @@ static struct sk_buff *e1000_alloc_rx_skb(struct e1000_adapter *adapter,
>> return skb;
>> }
>> + act = e1000_call_bpf(prog, page_address(p), length);
>> + switch (act) {
>> + case XDP_PASS:
>> + break;
>> + case XDP_TX:
>> + dma_sync_single_for_device(&pdev->dev,
>> + dma,
>> + length,
>> + DMA_TO_DEVICE);
>> + e1000_xmit_raw_frame(buffer_info, length,
>> + netdev, adapter);
>> + buffer_info->rxbuf.page = NULL;
>
>
> So I am trying to understand how pages are not leaked ?
>
>
Pages are being leaked thanks! v3 coming soon.
next prev parent reply other threads:[~2016-09-09 23:33 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
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 [this message]
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=57D346B6.3000204@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=eric.dumazet@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--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).