All of lore.kernel.org
 help / color / mirror / Atom feed
* Kernel hard_start_xmit performance vs SOCK_RAW performance
@ 2009-06-26 14:04 Gallus
  2009-06-26 14:08 ` Alan Cox
  0 siblings, 1 reply; 4+ messages in thread
From: Gallus @ 2009-06-26 14:04 UTC (permalink / raw)
  To: linux-kernel

Hi,
what path would you choose to rapidly generate packets:
1. Develop kernel space module and user space client tool.
The tool would call the module through ioctl() passing the packet
contents. The module would then construct sbk buffer and call
hard_start_xmit.

2. Develop only user space client tool
The tool would just sent packets through raw sockets.


I'm wondering if amount of system calls in (1) solution will not be a problem?

Which path is generally better?

-- 
Regards,
Gallus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Kernel hard_start_xmit performance vs SOCK_RAW performance
  2009-06-26 14:04 Kernel hard_start_xmit performance vs SOCK_RAW performance Gallus
@ 2009-06-26 14:08 ` Alan Cox
  2009-06-26 14:35   ` Gallus
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Cox @ 2009-06-26 14:08 UTC (permalink / raw)
  To: Gallus; +Cc: linux-kernel

On Fri, 26 Jun 2009 16:04:04 +0200
Gallus <gall.cwpl@gmail.com> wrote:

> Hi,
> what path would you choose to rapidly generate packets

Documentation/networking/pktgen.txt

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Kernel hard_start_xmit performance vs SOCK_RAW performance
  2009-06-26 14:08 ` Alan Cox
@ 2009-06-26 14:35   ` Gallus
  2009-06-26 14:47     ` Peter Chacko
  0 siblings, 1 reply; 4+ messages in thread
From: Gallus @ 2009-06-26 14:35 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

2009/6/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
> On Fri, 26 Jun 2009 16:04:04 +0200
> Gallus <gall.cwpl@gmail.com> wrote:
>
>> Hi,
>> what path would you choose to rapidly generate packets
>
> Documentation/networking/pktgen.txt

Thank you Alan for the answer.

However, my goal is to generate packets with certain *content* in them.

-- 
Regards,
Gallus
please CC me

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Kernel hard_start_xmit performance vs SOCK_RAW performance
  2009-06-26 14:35   ` Gallus
@ 2009-06-26 14:47     ` Peter Chacko
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Chacko @ 2009-06-26 14:47 UTC (permalink / raw)
  To: Gallus; +Cc: Alan Cox, linux-kernel

Did you try using PACKET socket interface  from your module  ?
(essentially as fast as hard-start-transmit() path ...there will be
tools that can be used for this purpose....I am not sure of any such
tool though...:-) you need to skip the scheduling (qdiscs) path also..

I think, Linux-net mailing list would be more appropriate to have this
discussion.

Thanks,
Peter

NetDiox computing systems
Bangalore-india
www.netdiox.com
080 2664 0708

On Fri, Jun 26, 2009 at 8:05 PM, Gallus<gall.cwpl@gmail.com> wrote:
> 2009/6/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> On Fri, 26 Jun 2009 16:04:04 +0200
>> Gallus <gall.cwpl@gmail.com> wrote:
>>
>>> Hi,
>>> what path would you choose to rapidly generate packets
>>
>> Documentation/networking/pktgen.txt
>
> Thank you Alan for the answer.
>
> However, my goal is to generate packets with certain *content* in them.
>
> --
> Regards,
> Gallus
> please CC me
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-06-26 14:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-26 14:04 Kernel hard_start_xmit performance vs SOCK_RAW performance Gallus
2009-06-26 14:08 ` Alan Cox
2009-06-26 14:35   ` Gallus
2009-06-26 14:47     ` Peter Chacko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.