On 11/08/2015 05:27 AM, John Fastabend wrote:
On 15-11-07 06:19 PM, Alexei Starovoitov wrote:
On Thu, Nov 05, 2015 at 10:39:15AM +0100, Daniel Borkmann wrote:
On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
On Thursday 05 November 2015 00:04:14 David Miller wrote:
As part of fixing y2038 problem
On 15-11-07 06:19 PM, Alexei Starovoitov wrote:
> On Thu, Nov 05, 2015 at 10:39:15AM +0100, Daniel Borkmann wrote:
>> On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
>>> On Thursday 05 November 2015 00:04:14 David Miller wrote:
As part of fixing y2038 problems, Arnd is going to have to make a new
On Thu, Nov 05, 2015 at 10:39:15AM +0100, Daniel Borkmann wrote:
> On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
> >On Thursday 05 November 2015 00:04:14 David Miller wrote:
> >>As part of fixing y2038 problems, Arnd is going to have to make a new
> >>version fo the AF_PACKET mmap() tpacker descript
On 11/05/2015 11:56 PM, Daniel Borkmann wrote:
On 11/05/2015 05:17 PM, Eric Dumazet wrote:
On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote:
On 11/05/2015 12:38 PM, Eric Dumazet wrote:
If I am not mistaken, af_packet also lacks the ability to properly set
skb->protocol
I noticed thi
On 11/05/2015 05:17 PM, Eric Dumazet wrote:
On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote:
On 11/05/2015 12:38 PM, Eric Dumazet wrote:
If I am not mistaken, af_packet also lacks the ability to properly set
skb->protocol
I noticed this using trafgen on a bonding device, when I did
On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote:
> On 11/05/2015 12:38 PM, Eric Dumazet wrote:
> > If I am not mistaken, af_packet also lacks the ability to properly set
> > skb->protocol
> >
> > I noticed this using trafgen on a bonding device, when I did my SYNFLOOD
> > tests for TCP li
From: Guy Harris
Date: Thu, 5 Nov 2015 00:14:51 -0800
> As a core libpcap developer, I will at least state that it works a
> *lot* better than v1 and v2 did. Having buffer slots that can hold
> only one packet is *really* suboptimal for packet capture; having
> buffer slots that can hold multipl
On 11/05/2015 12:38 PM, Eric Dumazet wrote:
On Thu, 2015-11-05 at 10:39 +0100, Daniel Borkmann wrote:
On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
On Thursday 05 November 2015 00:04:14 David Miller wrote:
As part of fixing y2038 problems, Arnd is going to have to make a new
version fo the AF_P
On Thu, 2015-11-05 at 10:39 +0100, Daniel Borkmann wrote:
> On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
> > On Thursday 05 November 2015 00:04:14 David Miller wrote:
> >> As part of fixing y2038 problems, Arnd is going to have to make a new
> >> version fo the AF_PACKET mmap() tpacker descriptors
On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
On Thursday 05 November 2015 00:04:14 David Miller wrote:
As part of fixing y2038 problems, Arnd is going to have to make a new
version fo the AF_PACKET mmap() tpacker descriptors in order to extend
the time values to 64-bit.
So I want everyone to th
On Thursday 05 November 2015 00:04:14 David Miller wrote:
> As part of fixing y2038 problems, Arnd is going to have to make a new
> version fo the AF_PACKET mmap() tpacker descriptors in order to extend
> the time values to 64-bit.
>
> So I want everyone to think about whether there are any other
On Nov 4, 2015, at 9:04 PM, David Miller wrote:
> As part of fixing y2038 problems, Arnd is going to have to make a new
> version fo the AF_PACKET mmap() tpacker descriptors in order to extend
> the time values to 64-bit.
>
> So I want everyone to think about whether there are any other changes
On Thu, Nov 05, 2015 at 12:04:14AM -0500, David Miller wrote:
> So I want everyone to think about whether there are any other changes
> we might want to make given that we have to make a v4 anyways.
One thing I would like to see is a field for a desired transmit time.
Time based scheduling is a ne
13 matches
Mail list logo
