fully filled in, passed to user space, and then
eventually passed back to the kernel for use with a new packet.
Signed-off-by: Jon Rosen <jro...@cisco.com>
---
There is a bug in net/packet/af_packet.c:tpacket_rcv in how it manages
the PACKET_RX_RING for versions TPACKET_V1 and TPACKET_V2. Th
properly. More discussion on this
change can be found in the additional comments section titled
"3. Discussion on packet_mmap ownership semantics:".
Signed-off-by: Jon Rosen <jro...@cisco.com>
---
Additional Comments Section
---
1. Descript
Forward link to a new proposed patch at:
https://www.mail-archive.com/netdev@vger.kernel.org/msg236629.html
On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
<willemdebruijn.ker...@gmail.com> wrote:
> On Sun, May 20, 2018 at 6:51 PM, Willem de Bruijn
> <willemdebruijn.ker...@gmail.com> wrote:
>> On Sat, May 19, 2018 at 8:07 AM, Jon Rosen <jro...@cisco.com> wrote:
>>&
On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
<willemdebruijn.ker...@gmail.com> wrote:
>On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) <jro...@cisco.com> wrote:
>> On Sunday, May 20, 2018 7:22 PM, Willem de Bruijn
>> <willemdebruijn.ker...@gmail.com> wro
On Monday, May 21, 2018 2:17 PM, Jon Rosen (jrosen) <jro...@cisco.com> wrote:
> On Monday, May 21, 2018 1:07 PM, Willem de Bruijn
> <willemdebruijn.ker...@gmail.com> wrote:
>> On Mon, May 21, 2018 at 8:57 AM, Jon Rosen (jrosen) <jro...@cisco.com> 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 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
> -Original Message-
> From: Willem de Bruijn [mailto:willemdebruijn.ker...@gmail.com]
> Sent: Wednesday, May 23, 2018 9:37 AM
> To: Jon Rosen (jrosen) <jro...@cisco.com>
> Cc: David S. Miller <da...@davemloft.net>; Willem de Bruijn
> <will...@g
> >> >One issue with the above proposed change to use TP_STATUS_IN_PROGRESS
> >> >is that the documentation of the tp_status field is somewhat
> >> >inconsistent. In some places it's described as TP_STATUS_KERNEL(0)
> >> >meaning the entry is owned by the kernel and
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > index e0f3f4a..264d7b2 100644
> > --- a/net/packet/af_packet.c
> > +++ b/net/packet/af_packet.c
> > @@ -2287,6 +2287,15 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> > net_device *dev,
> > if
On Wednesday, April 04, 2018 9:49 AM, Willem de Bruijn <will...@google.com>
wrote:
>
> On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen <jro...@cisco.com> wrote:
> > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> > casues the ring to get corrupt
12 matches
Mail list logo
