* [dpdk-dev] rte epoll functions
@ 2020-04-27 13:33 Liron Himi
2020-04-27 14:50 ` Stephen Hemminger
0 siblings, 1 reply; 5+ messages in thread
From: Liron Himi @ 2020-04-27 13:33 UTC (permalink / raw)
To: dpdk-dev; +Cc: Liron Himi
Hi,
We noticed that the implementation of rte_epoll_wait doesn't stopped on signal such as SIGINT.
Is anyone know why?
If that on purpose and cannot be changed, how application can exit gracefully when using rx interrupts for example.
Regards,
Liron
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte epoll functions
2020-04-27 13:33 [dpdk-dev] rte epoll functions Liron Himi
@ 2020-04-27 14:50 ` Stephen Hemminger
2020-04-27 15:01 ` David Marchand
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Hemminger @ 2020-04-27 14:50 UTC (permalink / raw)
To: Liron Himi; +Cc: dpdk-dev
On Mon, 27 Apr 2020 13:33:27 +0000
Liron Himi <lironh@marvell.com> wrote:
> Hi,
>
>
> We noticed that the implementation of rte_epoll_wait doesn't stopped on signal such as SIGINT.
>
> Is anyone know why?
>
> If that on purpose and cannot be changed, how application can exit gracefully when using rx interrupts for example.
>
> Regards,
> Liron
>
I noticed that, submitted a patch, and it has been unmerged for 9 months
https://patchwork.dpdk.org/patch/57047/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte epoll functions
2020-04-27 14:50 ` Stephen Hemminger
@ 2020-04-27 15:01 ` David Marchand
2020-04-27 16:57 ` Stephen Hemminger
0 siblings, 1 reply; 5+ messages in thread
From: David Marchand @ 2020-04-27 15:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Liron Himi, dpdk-dev
On Mon, Apr 27, 2020 at 4:51 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 27 Apr 2020 13:33:27 +0000
> Liron Himi <lironh@marvell.com> wrote:
>
> > Hi,
> >
> >
> > We noticed that the implementation of rte_epoll_wait doesn't stopped on signal such as SIGINT.
> >
> > Is anyone know why?
> >
> > If that on purpose and cannot be changed, how application can exit gracefully when using rx interrupts for example.
> >
> > Regards,
> > Liron
> >
>
> I noticed that, submitted a patch, and it has been unmerged for 9 months
> https://patchwork.dpdk.org/patch/57047/
- Indeed, there was no review nor any comment about the "bien fondé"
of this patch for 9 months,
- We don't need a new symbol, this should be fixed + symbol versioning
to keep current behavior.
--
David Marchand
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte epoll functions
2020-04-27 15:01 ` David Marchand
@ 2020-04-27 16:57 ` Stephen Hemminger
2020-04-28 1:43 ` Lukasz Wojciechowski
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Hemminger @ 2020-04-27 16:57 UTC (permalink / raw)
To: David Marchand; +Cc: Liron Himi, dpdk-dev
On Mon, 27 Apr 2020 17:01:21 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 27, 2020 at 4:51 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Mon, 27 Apr 2020 13:33:27 +0000
> > Liron Himi <lironh@marvell.com> wrote:
> >
> > > Hi,
> > >
> > >
> > > We noticed that the implementation of rte_epoll_wait doesn't stopped on signal such as SIGINT.
> > >
> > > Is anyone know why?
> > >
> > > If that on purpose and cannot be changed, how application can exit gracefully when using rx interrupts for example.
> > >
> > > Regards,
> > > Liron
> > >
> >
> > I noticed that, submitted a patch, and it has been unmerged for 9 months
> > https://patchwork.dpdk.org/patch/57047/
>
> - Indeed, there was no review nor any comment about the "bien fondé"
> of this patch for 9 months,
> - We don't need a new symbol, this should be fixed + symbol versioning
> to keep current behavior.
>
>
We do need a new symbol. People may want the old behavior.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] rte epoll functions
2020-04-27 16:57 ` Stephen Hemminger
@ 2020-04-28 1:43 ` Lukasz Wojciechowski
0 siblings, 0 replies; 5+ messages in thread
From: Lukasz Wojciechowski @ 2020-04-28 1:43 UTC (permalink / raw)
To: Stephen Hemminger, David Marchand; +Cc: Liron Himi, dpdk-dev
W dniu 27.04.2020 o 18:57, Stephen Hemminger pisze:
> On Mon, 27 Apr 2020 17:01:21 +0200
> David Marchand <david.marchand@redhat.com> wrote:
>
>> On Mon, Apr 27, 2020 at 4:51 PM Stephen Hemminger
>> <stephen@networkplumber.org> wrote:
>>> On Mon, 27 Apr 2020 13:33:27 +0000
>>> Liron Himi <lironh@marvell.com> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> We noticed that the implementation of rte_epoll_wait doesn't stopped on signal such as SIGINT.
>>>>
>>>> Is anyone know why?
>>>>
>>>> If that on purpose and cannot be changed, how application can exit gracefully when using rx interrupts for example.
>>>>
>>>> Regards,
>>>> Liron
>>>>
>>> I noticed that, submitted a patch, and it has been unmerged for 9 months
>>> https://protect2.fireeye.com/url?k=b1d79a91-ec04c185-b1d611de-0cc47a31ce4e-7c8024d7bc014fef&q=1&u=https%3A%2F%2Fpatchwork.dpdk.org%2Fpatch%2F57047%2F
>> - Indeed, there was no review nor any comment about the "bien fondé"
>> of this patch for 9 months,
>> - We don't need a new symbol, this should be fixed + symbol versioning
>> to keep current behavior.
>>
>>
> We do need a new symbol. People may want the old behavior.
Do we need new symbol and new functionality?
One can use signalfd to create a file descriptor for set of signals and
just pass it to epoll.
--
Lukasz Wojciechowski
Principal Software Engineer
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-28 1:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-27 13:33 [dpdk-dev] rte epoll functions Liron Himi
2020-04-27 14:50 ` Stephen Hemminger
2020-04-27 15:01 ` David Marchand
2020-04-27 16:57 ` Stephen Hemminger
2020-04-28 1:43 ` Lukasz Wojciechowski
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).