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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Tue, 05 Jul 2011 13:41:00 +0800
From:	Li Yu <raise.sail@...il.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: A GRO question

Hi,

	I have a question about GRO implementation, this indeed confuses me.

	I found that we assume that NAPI_GRO_CB(skb)->frag0 starts 
with a mac/L2 header in compare_ether_header(), which is called in
__napi_gro_receive()

	However, in further dev_gro_receive() -> ptype->gro_receive [inet_gro_receive],
we use same address as IPv4/L3 header, like below:

        off = skb_gro_offset(skb); //it should keep zero until now, in my words.
        hlen = off + sizeof(*iph);      
        iph = skb_gro_header_fast(skb, off);  //just return NAPI_GRO_CB(skb)->frag0 + 0

	So we forget that updating NAPI_GRO_CB(skb)->data_offset here, or I miss sth?

	And, in my understanding against igb source code, if rx_ring->rx_buffer_len < 1024 
(if we used large MTU), then igb driver use header split mode, in such case, the mac header
should be saved in skb->data : skb_put(skb, igb_get_hlen(rx_ring, rx_desc)), the rest data
is loaded by below skb_fill_page_desc() call. so NAPI_GRO_CB(skb)->frag0 should start with
L3 header. 

	Thanks.

Yu
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ