i.ro...@intel.com>; Reshetova, Elena <elena.reshet...@intel.com>;
>> Mike Maloney
>> <malo...@google.com>; Benjamin Poirier <bpoir...@suse.com>; Thomas Gleixner
>> <t...@linutronix.de>; Greg
>> Kroah-Hartman <gre...@linuxfoundation.org>; open
Willem de Bruijn
>> ; Eric Dumazet
>> ; Kees Cook ; David Windsor
>> ; Rosen,
>> Rami ; Reshetova, Elena ;
>> Mike Maloney
>> ; Benjamin Poirier ; Thomas Gleixner
>> ; Greg
>> Kroah-Hartman ; open list:NETWORKING [GENERAL]
>> ;
>> open lis
amin Poirier <bpoir...@suse.com>; Thomas Gleixner
> <t...@linutronix.de>; Greg
> Kroah-Hartman <gre...@linuxfoundation.org>; open list:NETWORKING [GENERAL]
> <net...@vger.kernel.org>;
> open list <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v2] pa
gt; Rami ; Reshetova, Elena ;
> Mike Maloney
> ; Benjamin Poirier ; Thomas Gleixner
> ; Greg
> Kroah-Hartman ; open list:NETWORKING [GENERAL]
> ;
> open list
> Subject: Re: [PATCH v2] packet: track ring entry use using a shadow ring to
> prevent RX ring overrun
>
> O
On Wed, May 23, 2018 at 7:54 AM, Jon Rosen (jrosen) wrote:
>> > For the ring, there is no requirement to allocate exactly the amount
>> > specified by the user request. Safer than relying on shared memory
>> > and simpler than the extra allocation in this patch would be to
On Wed, May 23, 2018 at 7:54 AM, Jon Rosen (jrosen) wrote:
>> > For the ring, there is no requirement to allocate exactly the amount
>> > specified by the user request. Safer than relying on shared memory
>> > and simpler than the extra allocation in this patch would be to allocate
>> > extra
> > For the ring, there is no requirement to allocate exactly the amount
> > specified by the user request. Safer than relying on shared memory
> > and simpler than the extra allocation in this patch would be to allocate
> > extra shadow memory at the end of the ring (and not mmap that).
> >
> >
> > For the ring, there is no requirement to allocate exactly the amount
> > specified by the user request. Safer than relying on shared memory
> > and simpler than the extra allocation in this patch would be to allocate
> > extra shadow memory at the end of the ring (and not mmap that).
> >
> >
> >>> I think the bigger issues as you've pointed out are the cost of
> >>> the additional spin lock and should the additional state be
> >>> stored in-band (fewer cache lines) or out-of band (less risk of
> >>> breaking due to unpredictable application behavior).
> >>
> >> We don't need the
> >>> I think the bigger issues as you've pointed out are the cost of
> >>> the additional spin lock and should the additional state be
> >>> stored in-band (fewer cache lines) or out-of band (less risk of
> >>> breaking due to unpredictable application behavior).
> >>
> >> We don't need the
On Tue, May 22, 2018 at 10:12 AM, Jon Rosen (jrosen) wrote:
> On Monday, May 21, 2018 2:17 PM, Jon Rosen (jrosen) wrote:
>> On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
>> wrote:
>>> On Mon, May 21, 2018 at 8:57 AM, Jon
On Tue, May 22, 2018 at 10:12 AM, Jon Rosen (jrosen) wrote:
> On Monday, May 21, 2018 2:17 PM, Jon Rosen (jrosen) wrote:
>> On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
>> wrote:
>>> On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen)
>>> wrote:
>
> ...snip...
>
>>>
>>> A setsockopt for
>>> I think the bigger issues as you've pointed out are the cost of
>>> the additional spin lock and should the additional state be
>>> stored in-band (fewer cache lines) or out-of band (less risk of
>>> breaking due to unpredictable application behavior).
>>
>> We don't need the spinlock if
>>> I think the bigger issues as you've pointed out are the cost of
>>> the additional spin lock and should the additional state be
>>> stored in-band (fewer cache lines) or out-of band (less risk of
>>> breaking due to unpredictable application behavior).
>>
>> We don't need the spinlock if
On Monday, May 21, 2018 2:17 PM, Jon Rosen (jrosen) wrote:
> On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
> wrote:
>> On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
...snip...
>>
>> A setsockopt for
On Monday, May 21, 2018 2:17 PM, Jon Rosen (jrosen) wrote:
> On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
> wrote:
>> On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
...snip...
>>
>> A setsockopt for userspace to signal a stricter interpretation of
>> tp_status to elide the
On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
wrote:
>On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
>> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
>> wrote:
>>> On Sun, May 20, 2018 at
On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
wrote:
>On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
>> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
>> wrote:
>>> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
>>> wrote:
On Sat, May 19, 2018 at 8:07 AM, Jon Rosen
On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
> wrote:
>> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
>> wrote:
>>> On Sat, May 19, 2018 at
On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) wrote:
> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
> wrote:
>> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
>> wrote:
>>> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
Fix PACKET_RX_RING bug for versions TPACKET_V1 and
On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
wrote:
> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
> wrote:
>> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
>>> Fix PACKET_RX_RING bug for versions
On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
wrote:
> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
> wrote:
>> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
>>> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
>>> casues the ring to get corrupted by allowing
On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
wrote:
> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
>> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
>> casues the ring to get corrupted by allowing multiple kernel
On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
wrote:
> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
>> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
>> casues the ring to get corrupted by allowing multiple kernel threads
>> to claim ownership of the same ring
On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> casues the ring to get corrupted by allowing multiple kernel threads
> to claim ownership of the same ring entry. Track ownership in a shadow
> ring
On Sat, May 19, 2018 at 8:07 AM, Jon Rosen wrote:
> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> casues the ring to get corrupted by allowing multiple kernel threads
> to claim ownership of the same ring entry. Track ownership in a shadow
> ring structure to prevent other
Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
casues the ring to get corrupted by allowing multiple kernel threads
to claim ownership of the same ring entry. Track ownership in a shadow
ring structure to prevent other kernel threads from reusing the same
entry before it's
Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
casues the ring to get corrupted by allowing multiple kernel threads
to claim ownership of the same ring entry. Track ownership in a shadow
ring structure to prevent other kernel threads from reusing the same
entry before it's
28 matches
Mail list logo