myri10ge conversion to non-contiguous skb

Quoted 6 lines

Quoted 2 lines

Imho you will want to work directly with pages shortly.

We had thought about doing this, but were a little nervous since we did not know of any other drivers that worked directly with pages. If this is an official direction to work directly with pages, we will.

s2io does. e1000 does it with skb frags.
If your hardware allows header split and driver can put headers into skb->data and real data into frag_list, that allows to create various interesting things like receiving zero-copy support and netchannels support. It is work in progress, not official direction currently, but this definitely will help your driver to support future high performance extensions.

During the submission of the myri10ge driver, some people raised the question of using pages (or any kind of non-contiguous skb) instead of our current 16kB contiguous skb. We are looking at this right now and it is not clear what solution is the best. From what we understand, Linux provides two mostly redundant mechanisms to handle discontinuous skb, the skb->frags and the skb->frag_list, s2io using the latter while e1000 uses the former. Is one or the other recommended? What is the purpose of having them both in the net core?

Quoted 8 lines · Brice Goglin

During the submission of the myri10ge driver, some people raised the question of using pages (or any kind of non-contiguous skb) instead of our current 16kB contiguous skb. We are looking at this right now and it is not clear what solution is the best. From what we understand, Linux provides two mostly redundant mechanisms to handle discontinuous skb, the skb->frags and the skb->frag_list, s2io using the latter while e1000 uses the former. Is one or the other recommended? What is the purpose of having them both in the net core?

you really only have one option, to use PAGE_SIZE pages and frags[] w/nr_frags. e1000 tried the frag_list option but that is used by ip reassembly and badly conflicts with driver generated frag_list.