Find the answer to your Linux question:
Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Problem with skb_queue_tail(), skb_dequeue() and working with the skb's


    I'm programming a protocol handler for a new ethernet type id for fast network transfers. I registered that handler with dev_add_pack(). Everytime I receive a vaild packet with that type id the receiving function is called and checks if the packed is vaild. If packed is valid, it gets added to a skb queue by calling skb_queue_tail().

    The module also spawns a new kthread which, if the queue is not empty, call skb_dequeue() to remove one skb from the list and then write that skb directly to the disk by calling vfs_write(). I'm aware that file I/O is a bad thing in the kernel but this will save some context switches.

    I noticed that skb->len is 14 bytes shorter than it should be. Im receiving 8192 bytes paylod + 14 bytes header but skb->len is only 8192 bytes. Second thing is, the data I wrote with vfs_write does in no way match the content I see with wireshark on the sending machine. It's a P2P link between both machines.

    The receiving function and the dequeue thread have both counters inside which I read from /proc. The show me that I receive numerous of valid skb's but none of them appear in the file on my disk. Sometimes there are some bytes of valid data but most of the time it's 0x00 or other data stored in my memory, like dmesg entries.

    Anyone with a good advice here? Thanks.

  2. #2

    Your length issue....

    the field "skb->len" refers specifically to the data portion of your packet, not your header which is the ethernet header of 14 bytes.

    You aren't seeing the same thing in your buffers makes me think you may be running into an "endianess" issue. Wireshark knows how to handle this.

    I don't want to think what's happening in the kernel while you are writing to a disk in a network module. Good luck with that.

    Hope this helps a little bit.


  3. #3

    I found out that all skb's I receive and dequeue are fragmented. I checked with skb_has_frags(). Can someone explain to me why the received skb's are fragmented / non-linear? If I reassemble the skb with skb_linearize() this would take CPU operations that I don't want to spend.

    I think that the fragmentation comes from the NETIF_F_SG supported feature of my NIC. Is this correct? Is there any other way to pass the dequeued skb linearized to a consumer function?


  4. $spacer_open
  5. #4


    Have you run modinfo on your ethernet driver to see what options it has available? Or look at the source code but perhaps you can play with the size of it's buffers (there is one called copybreak that may be of interest).


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts