netdev - Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet

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]

Date:   Mon, 07 Nov 2016 11:39:41 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     madalin.bucur@....com
Cc:     netdev@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, oss@...error.net,
        ppc@...dchasers.com, joe@...ches.com, pebolle@...cali.nl,
        joakim.tjernlund@...nsmode.se
Subject: Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA
 Ethernet

From: Madalin-Cristian Bucur <madalin.bucur@....com>
Date: Mon, 7 Nov 2016 16:32:16 +0000

>> -----Original Message-----
>> From: David Miller [mailto:davem@...emloft.net]
>> Sent: Monday, November 07, 2016 5:55 PM
>> 
>> From: Madalin-Cristian Bucur <madalin.bucur@....com>
>> Date: Mon, 7 Nov 2016 15:43:26 +0000
>> 
>> >> From: David Miller [mailto:davem@...emloft.net]
>> >> Sent: Thursday, November 03, 2016 9:58 PM
>> >>
>> >> Why?  By clearing this, you disallow an important fundamental way to do
>> >> performane testing, via pktgen.
>> >
>> > The Tx path in DPAA requires one to insert a back-pointer to the skb
>> into
>> > the Tx buffer. On the Tx confirmation path the back-pointer in the
>> buffer
>> > is used to release the skb. If Tx buffer is shared we'd alter the back-
>> pointer
>> > and leak/double free skbs. See also
>> 
>> Then have your software state store an array of SKB pointers, one for each
>> TX ring entry, just like every other driver does.
> 
> There is no Tx ring in DPAA. Frames are send out on QMan HW queues towards
> the FMan for Tx and then received back on Tx confirmation queues for cleanup.
> Array traversal would for sure cost more than using the back-pointer. Also,
> we can now process confirmations on a different core than the one doing Tx,
> we'd have to keep the arrays percpu and force the Tx conf on the same core.
> Or add locks.

Report back an integer index, like every scsi driver out there which
completes tagged queued block I/O operations asynchronously.  You can
associate the array with a specific TX confirmation queue.