mbox series

[0/2] Release ethdev shared memory on port cleanup

Message ID 20230818091321.2404089-1-david.marchand@redhat.com (mailing list archive)
Headers
Series Release ethdev shared memory on port cleanup |

Message

David Marchand Aug. 18, 2023, 9:13 a.m. UTC 
  This series was triggered after investigating why the
eal_flags_file_prefix_autotest unit test was failing in the case of
statically built binaries [1]).

For now, I went with a simple (naive) approach and put all accesses to the
shared data under a single lock: ethdev maintainers, it is your turn to
shine and give me reasons why we should keep the locks the way they
were ;-).
And let's see what the CI reports...

1: https://inbox.dpdk.org/dev/20230816153439.551501-12-bruce.richardson@intel.com/T/#m0e4c23f7be80bbdac076a387f4a2f9094dd07e0a

Comments

Morten Brørup Aug. 18, 2023, 10:18 a.m. UTC | #1 
> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Friday, 18 August 2023 11.13
> 
> This series was triggered after investigating why the
> eal_flags_file_prefix_autotest unit test was failing in the case of
> statically built binaries [1]).
> 
> For now, I went with a simple (naive) approach and put all accesses to the
> shared data under a single lock: ethdev maintainers, it is your turn to
> shine and give me reasons why we should keep the locks the way they
> were ;-).

This looks like a better solution to me. Perhaps because I'm not an ethdev maintainer. ;-)

> And let's see what the CI reports...
> 
> 1: https://inbox.dpdk.org/dev/20230816153439.551501-12-
> bruce.richardson@intel.com/T/#m0e4c23f7be80bbdac076a387f4a2f9094dd07e0a

Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
Thomas Monjalon Aug. 31, 2023, 3:34 p.m. UTC | #2 
18/08/2023 12:18, Morten Brørup:
> > From: David Marchand [mailto:david.marchand@redhat.com]
> > Sent: Friday, 18 August 2023 11.13
> > 
> > This series was triggered after investigating why the
> > eal_flags_file_prefix_autotest unit test was failing in the case of
> > statically built binaries [1]).
> > 
> > For now, I went with a simple (naive) approach and put all accesses to the
> > shared data under a single lock: ethdev maintainers, it is your turn to
> > shine and give me reasons why we should keep the locks the way they
> > were ;-).
> 
> This looks like a better solution to me. Perhaps because I'm not an ethdev maintainer. ;-)

Yes Morten, you didn't get the beauty of ethdev complexity :)