All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.r.fastabend@intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"gospo@redhat.com" <gospo@redhat.com>
Subject: Re: [net-next-2.6 PATCH v2] net: consolidate netif_needs_gso()	checks
Date: Sat, 06 Mar 2010 11:27:50 -0800	[thread overview]
Message-ID: <4B92ACB6.1090909@intel.com> (raw)
In-Reply-To: <20100227155245.GB3176@gondor.apana.org.au>

Herbert Xu wrote:
> On Sat, Feb 27, 2010 at 03:27:25AM -0800, David Miller wrote:
>   
>> If we have ip_summed == CHECKSUM_PARTIAL might some classifier
>> or packet scheduler action module require that the
>> transport header is setup properly before the SKB gets into
>> there?
>>     
>
> I think this is OK as the transport header setting was only there
> for backwards compatibility with certain drivers that relied on it.
> Its use was very much isolated.
>
> I just did a grep on net/sched and couldn't see anything obvious
> that uses transport_header.
>
>   
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index eb7f1a4..626124d 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -1835,12 +1835,40 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
>>>  {
>>>  	const struct net_device_ops *ops = dev->netdev_ops;
>>>  	int rc = NETDEV_TX_OK;
>>> +	int need_gso = netif_needs_gso(dev, skb);
>>> +
>>> +	if (!need_gso) {
>>> +		if (skb_has_frags(skb) &&
>>> +		    !(dev->features & NETIF_F_FRAGLIST) &&
>>> +		    __skb_linearize(skb))
>>> +			goto out_kfree_skb;
>>> +
>>> +		/* Fragmented skb is linearized if device does not support SG,
>>> +		 * or if at least one of fragments is in highmem and device
>>> +		 * does not support DMA from it.
>>> +		 */
>>> +		if (skb_shinfo(skb)->nr_frags &&
>>> +		    (!(dev->features & NETIF_F_SG) ||
>>> +		      illegal_highdma(dev, skb)) &&
>>> +		    __skb_linearize(skb))
>>> +			goto out_kfree_skb;
>>>       
>
> Please use skb_needs_linearize.
>
>   
>>> +		/* If packet is not checksummed and device does not support
>>> +		 * checksumming for this protocol, complete checksumming here.
>>> +		 */
>>> +		if (skb->ip_summed == CHECKSUM_PARTIAL) {
>>> +			skb_set_transport_header(skb, skb->csum_start -
>>> +				      skb_headroom(skb));
>>> +			if (!dev_can_checksum(dev, skb) &&
>>> +			     skb_checksum_help(skb))
>>> +				goto out_kfree_skb;
>>> +		}
>>> +	}
>>>  
>>>  	if (likely(!skb->next)) {
>>>  		if (!list_empty(&ptype_all))
>>>  			dev_queue_xmit_nit(skb, dev);
>>>  
>>> -		if (netif_needs_gso(dev, skb)) {
>>> +		if (need_gso) {
>>>  			if (unlikely(dev_gso_segment(skb)))
>>>  				goto out_kfree_skb;
>>>  			if (skb->next)
>>>       
>
> That whole if block should be moved into an else clause here:
>
> 		if (netif_needs_gso(dev, skb)) {
> 			if (unlikely(dev_gso_segment(skb)))
> 				goto out_kfree_skb;
> 			if (skb->next)
> 				goto gso;
> 		} else {
> 			do your thing
> 		}
>
> The reason is that the other paths only act on the fragments
> generated by GSO, so logically with your change we shouldn't
> apply any further software emulation to them, even if the device
> setting changed.
>
> Cheers,
>   
Herbert,

It looks like dev_gso_segment() could be used to "Verify header 
integrity only" according to the comment?  If this is true I think the 
logic should probably be

		if (netif_needs_gso(dev, skb)) {
			if (unlikely(dev_gso_segment(skb)))
				goto out_kfree_skb;
			if (skb->next)
				goto gso;
		} 
		do your thing

		

That way we linearize the skb if necessary in the case were 
dev_gso_segment() only verifies the header and does not return a list of 
segments.

thanks,
John.

  parent reply	other threads:[~2010-03-06 19:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27  0:20 [net-next-2.6 PATCH v2] net: consolidate netif_needs_gso() checks Jeff Kirsher
2010-02-27 11:27 ` David Miller
2010-02-27 15:52   ` Herbert Xu
2010-02-27 16:17     ` David Miller
2010-02-28  0:29       ` Herbert Xu
2010-02-28  8:29         ` David Miller
2010-02-28  8:30     ` David Miller
2010-03-06 19:27     ` John Fastabend [this message]
2010-03-07  1:43       ` Herbert Xu
2010-03-08 16:56         ` John Fastabend

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B92ACB6.1090909@intel.com \
    --to=john.r.fastabend@intel.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.