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
amin Poirier <bpoir...@suse.com>; Thomas Gleixner
> <t...@linutronix.de>; Greg
> Kroah-Hartman <gre...@linuxfoundation.org>; open list:NETWORKING [GENERAL]
> <netdev@vger.kernel.org>;
> open list <linux-ker...@vger.kernel.org>
> Subject: Re: [PATCH v2] pa
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
> > 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
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
>>> 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 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 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 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 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 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
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
14 matches
Mail list logo