[dpdk-dev] [PATCH v3] af_packet: make the device detachable

2016-02-29 Thread Wojciech Żmuda
Hi Bernard,

> Does making   rte_pmd_af_packet_devinit local result in an ABI breakage?
If someone uses it in their app, they'll be forced to change it.
However, as this function is not intentionally public and there is API
to create devices that finally calls rte_pmd_af_packet_devinit(), I'm
not sure if any special caution is needed here.

> Should the DPDK_2.0 structure be kept and a DPDK_2.3 structure added?
Should it be just `DPDK_2.3 { local: *} DPDK_2.0`? Doesn't inheritance
of DPDK_2.0 make the symbol also global in 2.3?

> A deprecation notice may need to be added to the 
> doc/guides/rel_notes/deprecation.rst  file.
As far as I understand, deprecation.rst is used to announce something
will be removed in the future release. Changes already done should be
moved from deprecation.rst to the release's .rst file. At least, this
is what I see in commit logs. If this change should be announced in
deprecation.rst, does this mean there should be another patch in the
future (after 2.3 release?) making this function static? And that
future patch will add DPDK_2.3 structure in the map file?

Thank you for your time,
Wojtek


[dpdk-dev] [PATCH v3] af_packet: make the device detachable

2016-03-02 Thread Wojciech Żmuda
Hi Panu,

>I think its okay to remove without going through the deprecation process.
> just drop the accidentally exported symbol from the 2.0 definition.
Well, this is what I've done so far. I'm going to post v4 patch
modifying release_16_04.rst  instead of release_2_3.rst, then. Thank
you for sharing your opinion on this topic.

Wojtek

2016-03-01 10:43 GMT+01:00 Panu Matilainen :
> On 02/29/2016 08:22 PM, Wojciech ?muda wrote:
>>
>> Hi Bernard,
>>
>>> Does making   rte_pmd_af_packet_devinit local result in an ABI breakage?
>>
>> If someone uses it in their app, they'll be forced to change it.
>> However, as this function is not intentionally public and there is API
>> to create devices that finally calls rte_pmd_af_packet_devinit(), I'm
>> not sure if any special caution is needed here.
>
>
> Yeah this is a bit of a gray area. Strictly speaking it certainly is an ABI
> break, but given that the function is documented as internal-only and
> there's a proper, public way to create the device, there's no good excuse
> for anybody to be using it. I think its okay to remove without going through
> the deprecation process.
>
>>
>>> Should the DPDK_2.0 structure be kept and a DPDK_2.3 structure added?
>>
>> Should it be just `DPDK_2.3 { local: *} DPDK_2.0`? Doesn't inheritance
>> of DPDK_2.0 make the symbol also global in 2.3?
>
>
> Since there are no symbols being exported I dont see any point in changing
> the version, just drop the accidentally exported symbol from the 2.0
> definition.
>
> - Panu -
>
>
>>> A deprecation notice may need to be added to the
>>> doc/guides/rel_notes/deprecation.rst  file.
>>
>> As far as I understand, deprecation.rst is used to announce something
>> will be removed in the future release. Changes already done should be
>> moved from deprecation.rst to the release's .rst file. At least, this
>> is what I see in commit logs. If this change should be announced in
>> deprecation.rst, does this mean there should be another patch in the
>> future (after 2.3 release?) making this function static? And that
>> future patch will add DPDK_2.3 structure in the map file?
>>
>> Thank you for your time,
>> Wojtek
>>
>


[dpdk-dev] [PATCH v2] af_packet: make the device detachable

2016-02-10 Thread Wojciech Żmuda
Hi Bruce,

>The use of "deinitialization" sounds awkward

Thank you for your interest. I called it deinitialization in
opposition to an initialization of a device. As I'm not a native
English speaker, I trust your opinion and I'll try to rephrase this.

Hi Bernard,

>What parameters do you use with --vdev option in testpmd

I launch testpmd like this:
# ./testpmd -c f -n 4 --vdev 'eth_af_packet0,iface=eth2' -- -i
--port-topology=chained

Then I can see that af_packet starts:

PMD: Initializing pmd_af_packet for eth_af_packet0
PMD: eth_af_packet0: AF_PACKET MMAP parameters:
PMD: eth_af_packet0:block size 4096
PMD: eth_af_packet0:block count 256
PMD: eth_af_packet0:frame size 2048
PMD: eth_af_packet0:frame count 512
PMD: eth_af_packet0: creating AF_PACKET-backed ethdev on numa socket

When I get to the CLI, I do as follows:

Checking link statuses...
Port 0 Link Up - speed 1 Mbps - full-duplex
Done
testpmd> port stop 0
Stopping ports...
Checking link statuses...
Port 0 Link Down
Done
testpmd> port close 0
Closing ports...
Done
testpmd> port detach 0
Detaching a port...
PMD: Closing AF_PACKET ethdev on numa socket 0
Port 'eth_af_packet0' is detached. Now total ports is 0
Done
testpmd>

In opposition, without the patch detach is impossible:

testpmd> port detach 0
Detaching a port...
EAL: Driver, cannot detach the device
testpmd>


Bernard, Bruce, I have a question, if I may. Do you know what is the
reason that rte_pmd_af_packet_devinit() is the only non-static device
initialization function among all the dpdk drivers? There's even a
comment in the rte_eth_af_packet.h:

/**
 * For use by the EAL only. Called as part of EAL init to set up any dummy NICs
 * configured on command line.
 */
int rte_pmd_af_packet_devinit(const char *name, const char *params);

Despite the comment above, I cannot see this function being called
directly anywhere. Is there any reason it is implemented this way? Or
should I change the definition to static, as it should be called via
proper API functions?

Thank you for your time,
Wojtek

2016-02-09 17:37 GMT+01:00 Bruce Richardson :
> On Tue, Feb 09, 2016 at 05:09:06PM +0100, Wojciech Zmuda wrote:
>> Implement rte_pmd_af_packet_devuninit() exposed through struct
>> rte_driver.uninit() and set dev_flags to RTE_ETH_DEV_DETACHABLE,
>> to allow af_packet device deinitialization with API function
>> rte_eth_dev_detach(). This fixes memory leak by freeing memory
>> allocated during initialization.
>> During device initialization copy device name to ethdev->data to make
>> it compatible with rte_eth_dev_allocated().
>>
>> Signed-off-by: Wojciech Zmuda 
>> ---
>> v2:
>> * Fixed typo and a comment.
>> * Added feature to the 2.3 release notes.
>> * Free memory allocated for rx and tx queues.
>>
>>  doc/guides/rel_notes/release_2_3.rst  |  4 
>>  drivers/net/af_packet/rte_eth_af_packet.c | 37 
>> ++-
>>  2 files changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/guides/rel_notes/release_2_3.rst 
>> b/doc/guides/rel_notes/release_2_3.rst
>> index 7945694..4694646 100644
>> --- a/doc/guides/rel_notes/release_2_3.rst
>> +++ b/doc/guides/rel_notes/release_2_3.rst
>> @@ -39,6 +39,10 @@ This section should contain new features added in this 
>> release. Sample format:
>>
>>Enabled virtio 1.0 support for virtio pmd driver.
>>
>> +* **Added af_packet driver deinitialization function.**
>> +
>> +  Implemented rte_pmd_af_packet_devuninit() exposed through struct
>> +  rte_driver.uninit() to allow af_packet device deinitialization with API 
>> function.
>>
>
> The use of "deinitialization" sounds awkward, and the overall text maybe 
> could be
> made less technical. Maybe talk about "allowing dynamic removal" of af_packet
> devices [or even hotplug of them]?
>
> /Bruce