That is another solution; which function do you call to transmit:
dev_queue_xmit? Do you handle fragmentation, and hence need to receive
ICMP replies?
Claude
raz ben yehuda wrote:
i have the same issue in my modules. I created a light udp stack and i
am transmitting in softirq context.
On Mon, 2009-05-18 at 13:07 -0400, Claude Robitaille wrote:
Thanks Mulyadi,
this is what I was suspecting would be the way to go. But I am more
familiar, still, with 2.4 but I found interesting reading about work queues.
Someone else is also suggesting to use netfilter and create a module of
my own. Any one knows how to compare the 2 solutions?
In the packet handler, running in softirq, I will have to handle sk_buff
list, or lists. This list will be used by both the packet handler and
the work job so there is a need to atomatically manipulate it. I am sure
there are quit a bit of list manipulation define or function in 2.6 but
I do not know where to look. Any pointers? Or names?
Claude
Mulyadi Santosa wrote:
Hi Claude....
Just trying to give you idea...
On Mon, May 18, 2009 at 4:35 AM, Claude Robitaille <clauder@xxxxxxxxxxxx> wrote:
Hi all,
i am trying to create a module that will receive frames from a physical
interface, using a packet handler registered via dev_add_pack, mangle the
frame content and send it over a UDP socket. To transmit over UDP I created
a socket and I am sending the frame using sock_sendmsg. It is mostly working
except that I am getting some error and, above all, the kernel is crashing
:-(
The error message that I get the most is "scheduling while atomic". This
leads me to believe that sock_sendmsg cannot be used while in softirq
context, which, as per my understanding, is the context when the packet
handlers are called.
So, I am a little puzzled as to what are my options. Should I use some
queuing and then dispatch something that will execute in the proper context?
Or try to find a lower entry point into UDP that would work in softirq
context? Any suggestions?
As you know, the tcp/ip code path is quite long, IIRC it could reach
10-15 level deep. So, I think you'll agree we can call it "fast path".
Furthermore, we shouldn't make it slower with unnecessary work.
Therefore, IMO, if you could somehow copy or move your mangled frame
into separate queue and process it in process context (probably using
workqueue), I think it's the way to go.
regards,
Mulyadi.
--
Claude Robitaille
CTO
Accedian Networks
514-764-0119
clauder@xxxxxxxxxxxx
begin:vcard
fn:Claude Robitaille
n:Robitaille;Claude
email;internet:clauder@xxxxxxxxxxxx
tel;work:514-764-0119
tel;cell:514-796-7225
x-mozilla-html:TRUE
version:2.1
end:vcard
