All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: "Rose, Gregory V" <gregory.v.rose@intel.com>,
	Ben Hutchings <ben@decadent.org.uk>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"Gasparakis, Joseph" <joseph.gasparakis@intel.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"gospo@redhat.com" <gospo@redhat.com>,
	"sassmann@redhat.com" <sassmann@redhat.com>
Subject: Re: [net-next] vxlan: Advertise SCTP checksum offloads
Date: Tue, 29 Apr 2014 13:09:52 -0400	[thread overview]
Message-ID: <535FDCE0.80803@gmail.com> (raw)
In-Reply-To: <C5551D9AAB213A418B7FD5E4A6F30A0784A4DA91@ORSMSX108.amr.corp.intel.com>

On 04/29/2014 12:10 PM, Rose, Gregory V wrote:
> 
>> -----Original Message-----
>> From: Ben Hutchings [mailto:ben@decadent.org.uk]
>> Sent: Tuesday, April 29, 2014 5:39 AM
>> To: Kirsher, Jeffrey T
>> Cc: davem@davemloft.net; Rose, Gregory V; netdev@vger.kernel.org;
>> gospo@redhat.com; sassmann@redhat.com
>> Subject: Re: [net-next] vxlan: Advertise SCTP checksum offloads
>>
>> On Mon, 2014-04-28 at 12:52 -0700, Jeff Kirsher wrote:
>>> From: Greg Rose <gregory.v.rose@intel.com>
>>>
>>> Some HW can offload encapsulated SCTP checksums.  Advertise the
>>> capability for such cases.
>>
>> Don't we need a software fallback on the output path before doing this?
> 
> I believe that the vxlan driver will compare offload features with the lower device hw_enc_feature flags and if the HW doesn't have the offload then it won't be advertised to the sctp driver.  In that case the sctp driver will do its own checksumming.  At least that is the behavior I saw.
> 

I've been looking at this and can't see vxlan doing any feature
comparisons/disabling...

At the time SCTP tries to do checksum, it will see hw offload
support and set checksum as partial.  That will be propagated
all the way to vxlan which will set encapsulation and pass it on.
At next dev_hard_start_xmit(), we'll look at hw_enc_features,
but it won't matter since SCTP packets are never GSO.

So, we'll use the non-gso code path and still send with partial
checksum set.  Now, if the driver supports encapsulated SCTP,
then it will work.  If it doesn't, the udp checksum will be computed,
but not the sctp one.

-vlad

> I'm adding Joseph Gasparakis.  He might have a better answer.
> 
> - Greg
> 
>>
>> Ben.
>>
>>> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>>> Acked-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
>>> Acked-by: Shannon Nelson <shannon.nelson@intel.com>
>>> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> ---
>>>  drivers/net/vxlan.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index
>>> 1dfee9a..988208f 100644
>>> --- a/drivers/net/vxlan.c
>>> +++ b/drivers/net/vxlan.c
>>> @@ -2293,6 +2293,7 @@ static void vxlan_setup(struct net_device *dev)
>>>  	dev->features	|= NETIF_F_SG | NETIF_F_HW_CSUM;
>>>  	dev->features   |= NETIF_F_RXCSUM;
>>>  	dev->features   |= NETIF_F_GSO_SOFTWARE;
>>> +	dev->features   |= NETIF_F_SCTP_CSUM;
>>>
>>>  	dev->vlan_features = dev->features;
>>>  	dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
>>
>> --
>> Ben Hutchings
>> Q.  Which is the greater problem in the world today, ignorance or apathy?
>> A.  I don't know and I couldn't care less.
> N�����r��y���b�X��ǧv�^�)޺{.n�+���z�^�)���w*\x1fjg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
> 

  reply	other threads:[~2014-04-29 17:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28 19:52 [net-next] vxlan: Advertise SCTP checksum offloads Jeff Kirsher
2014-04-29 12:39 ` Ben Hutchings
2014-04-29 16:10   ` Rose, Gregory V
2014-04-29 17:09     ` Vlad Yasevich [this message]
2014-04-29 17:34       ` Joseph Gasparakis
2014-04-29 18:00         ` Vlad Yasevich
2014-04-29 19:25           ` Joseph Gasparakis
2014-04-29 19:25             ` Vlad Yasevich
2014-04-29 20:59               ` Joseph Gasparakis
2014-05-01 11:09                 ` Daniel Borkmann
2014-04-29 15:28 ` Tom Herbert

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=535FDCE0.80803@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=ben@decadent.org.uk \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=gregory.v.rose@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=joseph.gasparakis@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=sassmann@redhat.com \
    /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.