On Mon, Mar 23, 2015 at 02:03:54PM +0200, Vadim Kochan wrote:
> On Mon, Mar 23, 2015 at 01:07:24PM +0200, Vadim Kochan wrote:
> > On Mon, Mar 23, 2015 at 12:12:54PM +0100, Daniel Borkmann wrote:
> > > On 03/23/2015 11:37 AM, Vadim Kochan wrote:
> > > >On Mon, Mar 23, 2015 at 11:25:26AM +0100, Lorenzo Pistone wrote:
> > > ...
> > > >Thats what I got on 3.18 with the same cfg file:
> > > >
> > > >$ trafgen/trafgen -c ~/trafgen.cfg -o wlp3s0 -n 1
> > > > 4 packets to schedule
> > > > 168 bytes in total
> > > >Running! Hang up with ^C!
> > > >
> > > >
> > > > 0 packets outgoing
> > > > 0 bytes outgoing
> > > > 0 sec, 0 usec on CPU0 (0 packets)
> > > > 0 sec, 0 usec on CPU1 (0 packets)
> > > > 0 sec, 0 usec on CPU2 (0 packets)
> > > > 0 sec, 0 usec on CPU3 (0 packets)
> > > >
> > > >Seems packet was not sent from trafgen ?
> > >
> > > If you increase -n e.g. to 64 or omit -n entirely, does that work?
> > > Looks like a trafgen bug.
> >
> > Yeah, w/o -n my sniffer on the other side was totally stucked:-) so it
> > helped.
>
> Meanwhile I see (by printf) that ctx->num is zeroed in xmit_packet_precheck
> where it is rounded.
>
> Regards,
My understanding is that it works in slow path because in slow path we
use 1 cpu, but in fast path the numbers of packets is multiplied by
number of cpus in xmit_packet_precheck(...):
plen_total = __wait_and_sum_others(ctx, cpu);
which in my case plen_total is 4 when I specified -n 1 and then it is
rounded to 0 - plen=1 plen_total=4 orig=1:
ctx->num = (unsigned long) round((1.0 * plen / plen_total) * orig);
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
