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. > > > > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
