On 16-04-10 02:38 PM, Brenden Blanco wrote:
I always go for the lowest hanging fruit.
Which to me is the 60% time spent above the driver level as shown above.
[..]
It seemed it was the driver path in your case. When we removed
the driver overhead (as demoed at the tc workshop in netdev11) we
On Sat, Apr 09, 2016 at 01:27:03PM -0400, Jamal Hadi Salim wrote:
> On 16-04-09 12:43 PM, Brenden Blanco wrote:
> >On Sat, Apr 09, 2016 at 10:48:05AM -0400, Jamal Hadi Salim wrote:
>
>
> >>Ok, sorry - should have looked this far before sending earlier email.
> >>So when you run concurently you se
On 16-04-09 12:43 PM, Brenden Blanco wrote:
On Sat, Apr 09, 2016 at 10:48:05AM -0400, Jamal Hadi Salim wrote:
Ok, sorry - should have looked this far before sending earlier email.
So when you run concurently you see about 5Mpps per core but if you
shoot all traffic at a single core you see 20
On Sat, Apr 09, 2016 at 10:48:05AM -0400, Jamal Hadi Salim wrote:
> On 16-04-08 12:48 AM, Brenden Blanco wrote:
> >Add a sample program that only drops packets at the
> >BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program,
> >observed single core rate is ~19.5Mpps.
> >
> >Other tests
On 16-04-08 12:48 AM, Brenden Blanco wrote:
Add a sample program that only drops packets at the
BPF_PROG_TYPE_PHYS_DEV hook of a link. With the drop-only program,
observed single core rate is ~19.5Mpps.
Other tests were run, for instance without the dropcnt increment or
without reading from the
