lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 13 Oct 2007 16:53:59 +0200 From: Kristian Evensen <kristrev@....uio.no> To: kristrev@...dent.matnat.uio.no Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org, linux-net@...r.kernel.org Subject: Re: Non-linear SKBs Reading through my mail again, I see that I was a bit unclear. What I want to achieve is to share a frag between to skbs (where one has no earlier referance to it). Sorry. kristrev@...dent.matnat.uio.no wrote: >> If the underlying device can do scatter-gather and checksumming, >> the TCP code builds outgoing packets by copying user date into >> full system pages, and then attaching those pages into the SKB. >> The protocol headers sit under the skb->data linear area, and >> the user data mostly sits in the user pages under >> skb_shinfo(skb)->frags[] >> >> This increases the density of data packed into the memory allocated >> compared to using skb->data for it. It also enormously simplifies >> the logic necessary to support TSO. >> > > Thank you very much, I think I am starting to get it now and coming to > think of it this will make my patch much more elegant. I have spent the > day reading more code, and am wondering if something along the likes of > this piece of code will do what I want ("copy" the data from the next skb > in the retransmission queue into this skb): > > //Do preliminary checks to see if the "new" packet will be within mss, > that this_skb->nr_frags + next_skb->nr_frags < MAX_SKB_FRAGS and so on > > int i; > int this_frags = this_skb->nr_frags; > > for(i=0; i<next_skb->nr_frags; i++) > //Does the "copy" > this_skb->frags[this_frags + i] = next_skb->frags[i]; > > this_skb->data_len += next_skb->data_len; > this_skb->truesize += next_skb->data_len; > this_skb->nr_frags += next_skb->nr_frags; > > //Update TSO? > > By the way, am I correct in my assumption that one SKB's frags is stored > linearly in the frags-array? Or have I made a horrible misunderstanding? > :) > > One of the things that I have yet to understand is the frag_list in the > skb_shared_info-struct. Does this contain all skb's that "use" this frag > and works as a sort of referance counter (frag won't be removed until the > variable is NULL and I have to append this_skb to the list), or is it > something else? > > Thanks again for all help. > > -Kristian > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists