diff mbox

[dpdk-dev] ip_chksum not updated in ipsec-secgw application

Message ID DB3PR04MB1073850452F0411F413F395E6360@DB3PR04MB107.eurprd04.prod.outlook.com (mailing list archive)
State Rejected, archived
Headers

Commit Message

Akhil Goyal July 18, 2016, 12:41 p.m. UTC 
  Hi,

In Ipsec-secgw application, while adding the outer IP header, it seems that the application does not update the checksum value for outbound packets. This result in incorrect ip->checksum in the encrypted packet.

Please let me know if the checksum value is updated somewhere else or not.

Also In case of inner ip header also the TTL value is decremented by one but the checksum value is not updated. Is it intentional or it is done somewhere else?

After addition of following code, the checksum looks good and the encrypted packets are good.

Regards,
Akhil

Comments

Sergio Gonzalez Monroy July 18, 2016, 12:57 p.m. UTC | #1 
Hi,

On 18/07/2016 13:41, Akhil Goyal wrote:
> Hi,
>
> In Ipsec-secgw application, while adding the outer IP header, it seems that the application does not update the checksum value for outbound packets. This result in incorrect ip->checksum in the encrypted packet.
>
> Please let me know if the checksum value is updated somewhere else or not.
>
> Also In case of inner ip header also the TTL value is decremented by one but the checksum value is not updated. Is it intentional or it is done somewhere else?

It is intentional. The application is using IP checksum offload but just 
looking now at the code there is a bug for IPv6 packets where the flag 
does not get setup.
Is it only for IPv6 traffic that you are having this issue?

For IPv4 traffic the PKT_TX_IP_CKSUM flag is setup in 'prepare_tx_pkt' 
function in ipsec-secgw.c

Sergio

> After addition of following code, the checksum looks good and the encrypted packets are good.
>
> diff --git a/examples/ipsec-secgw/ipip.h b/examples/ipsec-secgw/ipip.h
> index 322076c..0f7b60f 100644
> --- a/examples/ipsec-secgw/ipip.h
> +++ b/examples/ipsec-secgw/ipip.h
> @@ -41,6 +41,24 @@
> #include <rte_mbuf.h>
>
> #define IPV6_VERSION (6)
> +static inline uint16_t
> +ip_sum(const unaligned_uint16_t *hdr, int hdr_len)
> +{
> +       uint32_t sum = 0;
> +
> +       while (hdr_len > 1)
> +       {
> +               sum += *hdr++;
> +               if (sum & 0x80000000)
> +                       sum = (sum & 0xFFFF) + (sum >> 16);
> +               hdr_len -= 2;
> +       }
> +
> +       while (sum >> 16)
> +               sum = (sum & 0xFFFF) + (sum >> 16);
> +
> +       return ~sum;
> +}
>
> static inline  struct ip *
> ip4ip_outbound(struct rte_mbuf *m, uint32_t offset, uint32_t src, uint32_t dst)
> @@ -71,7 +89,8 @@ ip4ip_outbound(struct rte_mbuf *m, uint32_t offset, uint32_t src, uint32_t dst)
>
>          outip->ip_src.s_addr = src;
>          outip->ip_dst.s_addr = dst;
> -
> +       outip->ip_sum = 0;
> +       outip->ip_sum = ip_sum((const unaligned_uint16_t *)outip, sizeof(struct ip));
>          return outip;
> }
>
> Regards,
> Akhil
>
Thomas Monjalon July 18, 2016, 1:20 p.m. UTC | #2 
2016-07-18 13:57, Sergio Gonzalez Monroy:
> On 18/07/2016 13:41, Akhil Goyal wrote:
> > In Ipsec-secgw application, while adding the outer IP header,
> > it seems that the application does not update the checksum value
> > for outbound packets. This result in incorrect ip->checksum in
> > the encrypted packet.
[...]
> 
> It is intentional. The application is using IP checksum offload

The correct behaviour is to have a software fallback (using rte_ip.h)
for drivers which do not support checksum offload.
But given it is just an example, it is normal to have this kind of
constraint. However I think it should be explained in its doc.
And a list of tested NICs would be nice to have.
Akhil Goyal July 18, 2016, 1:49 p.m. UTC | #3 
On 7/18/2016 6:27 PM, Sergio Gonzalez Monroy wrote:
> Hi,
>
> On 18/07/2016 13:41, Akhil Goyal wrote:
>> Hi,
>>
>> In Ipsec-secgw application, while adding the outer IP header, it seems
>> that the application does not update the checksum value for outbound
>> packets. This result in incorrect ip->checksum in the encrypted packet.
>>
>> Please let me know if the checksum value is updated somewhere else or
>> not.
>>
>> Also In case of inner ip header also the TTL value is decremented by
>> one but the checksum value is not updated. Is it intentional or it is
>> done somewhere else?
>
> It is intentional. The application is using IP checksum offload but just
> looking now at the code there is a bug for IPv6 packets where the flag
> does not get setup.
> Is it only for IPv6 traffic that you are having this issue?
>
> For IPv4 traffic the PKT_TX_IP_CKSUM flag is setup in 'prepare_tx_pkt'
> function in ipsec-secgw.c
>
> Sergio
>

Thanks Sergio, got your point. I missed the flag. I was using it for IPv4.

Akhil
Akhil Goyal July 18, 2016, 1:53 p.m. UTC | #4 
On 7/18/2016 6:50 PM, Thomas Monjalon wrote:
> 2016-07-18 13:57, Sergio Gonzalez Monroy:
>> On 18/07/2016 13:41, Akhil Goyal wrote:
>>> In Ipsec-secgw application, while adding the outer IP header,
>>> it seems that the application does not update the checksum value
>>> for outbound packets. This result in incorrect ip->checksum in
>>> the encrypted packet.
> [...]
>>
>> It is intentional. The application is using IP checksum offload
>
> The correct behaviour is to have a software fallback (using rte_ip.h)
> for drivers which do not support checksum offload.
> But given it is just an example, it is normal to have this kind of
> constraint. However I think it should be explained in its doc.
> And a list of tested NICs would be nice to have.
>
Agreed. The driver that I was using did not enable checksum offload. It 
is good to have a fallback option.
Sergio Gonzalez Monroy July 18, 2016, 1:57 p.m. UTC | #5 
On 18/07/2016 14:53, Akhil Goyal wrote:
> On 7/18/2016 6:50 PM, Thomas Monjalon wrote:
>> 2016-07-18 13:57, Sergio Gonzalez Monroy:
>>> On 18/07/2016 13:41, Akhil Goyal wrote:
>>>> In Ipsec-secgw application, while adding the outer IP header,
>>>> it seems that the application does not update the checksum value
>>>> for outbound packets. This result in incorrect ip->checksum in
>>>> the encrypted packet.
>> [...]
>>>
>>> It is intentional. The application is using IP checksum offload
>>
>> The correct behaviour is to have a software fallback (using rte_ip.h)
>> for drivers which do not support checksum offload.
>> But given it is just an example, it is normal to have this kind of
>> constraint. However I think it should be explained in its doc.
>> And a list of tested NICs would be nice to have.
>>
> Agreed. The driver that I was using did not enable checksum offload. 
> It is good to have a fallback option.
>

That's a good point.
So would it be enough to call out in the sample app guide that we use IP 
checksum offload and
show a warning in case the Driver does not support such offload?

Sergio
Sergio Gonzalez Monroy July 18, 2016, 2 p.m. UTC | #6 
On 18/07/2016 14:49, Akhil Goyal wrote:
> On 7/18/2016 6:27 PM, Sergio Gonzalez Monroy wrote:
>> Hi,
>>
>> On 18/07/2016 13:41, Akhil Goyal wrote:
>>> Hi,
>>>
>>> In Ipsec-secgw application, while adding the outer IP header, it seems
>>> that the application does not update the checksum value for outbound
>>> packets. This result in incorrect ip->checksum in the encrypted packet.
>>>
>>> Please let me know if the checksum value is updated somewhere else or
>>> not.
>>>
>>> Also In case of inner ip header also the TTL value is decremented by
>>> one but the checksum value is not updated. Is it intentional or it is
>>> done somewhere else?
>>
>> It is intentional. The application is using IP checksum offload but just
>> looking now at the code there is a bug for IPv6 packets where the flag
>> does not get setup.
>> Is it only for IPv6 traffic that you are having this issue?
>>

Duh! moment here.
No checksum for IPv6, that's why the flag is not setup so the code is 
correct
as it is, it just needs IPv4 checksum offload support.

Sergio

>> For IPv4 traffic the PKT_TX_IP_CKSUM flag is setup in 'prepare_tx_pkt'
>> function in ipsec-secgw.c
>>
>> Sergio
>>
>
> Thanks Sergio, got your point. I missed the flag. I was using it for 
> IPv4.
>
> Akhil
>
>
Thomas Monjalon July 18, 2016, 2:09 p.m. UTC | #7 
2016-07-18 14:57, Sergio Gonzalez Monroy:
> On 18/07/2016 14:53, Akhil Goyal wrote:
> > On 7/18/2016 6:50 PM, Thomas Monjalon wrote:
> >> 2016-07-18 13:57, Sergio Gonzalez Monroy:
> >>> On 18/07/2016 13:41, Akhil Goyal wrote:
> >>>> In Ipsec-secgw application, while adding the outer IP header,
> >>>> it seems that the application does not update the checksum value
> >>>> for outbound packets. This result in incorrect ip->checksum in
> >>>> the encrypted packet.
> >> [...]
> >>>
> >>> It is intentional. The application is using IP checksum offload
> >>
> >> The correct behaviour is to have a software fallback (using rte_ip.h)
> >> for drivers which do not support checksum offload.
> >> But given it is just an example, it is normal to have this kind of
> >> constraint. However I think it should be explained in its doc.
> >> And a list of tested NICs would be nice to have.
> >>
> > Agreed. The driver that I was using did not enable checksum offload. 
> > It is good to have a fallback option.
> 
> That's a good point.
> So would it be enough to call out in the sample app guide that we use IP 
> checksum offload and
> show a warning in case the Driver does not support such offload?

Yes
and a list of tested NICs would make it perfect :)
Sergio Gonzalez Monroy July 18, 2016, 2:25 p.m. UTC | #8 
On 18/07/2016 15:09, Thomas Monjalon wrote:
> 2016-07-18 14:57, Sergio Gonzalez Monroy:
>> On 18/07/2016 14:53, Akhil Goyal wrote:
>>> On 7/18/2016 6:50 PM, Thomas Monjalon wrote:
>>>> 2016-07-18 13:57, Sergio Gonzalez Monroy:
>>>>> On 18/07/2016 13:41, Akhil Goyal wrote:
>>>>>> In Ipsec-secgw application, while adding the outer IP header,
>>>>>> it seems that the application does not update the checksum value
>>>>>> for outbound packets. This result in incorrect ip->checksum in
>>>>>> the encrypted packet.
>>>> [...]
>>>>> It is intentional. The application is using IP checksum offload
>>>> The correct behaviour is to have a software fallback (using rte_ip.h)
>>>> for drivers which do not support checksum offload.
>>>> But given it is just an example, it is normal to have this kind of
>>>> constraint. However I think it should be explained in its doc.
>>>> And a list of tested NICs would be nice to have.
>>>>
>>> Agreed. The driver that I was using did not enable checksum offload.
>>> It is good to have a fallback option.
>> That's a good point.
>> So would it be enough to call out in the sample app guide that we use IP
>> checksum offload and
>> show a warning in case the Driver does not support such offload?
> Yes
> and a list of tested NICs would make it perfect :)

There is no mention of specific tested hardware in the example guides, 
is there?

I would prefer to just point to doc/guides/nics/overview.rst to check if 
the NIC supports
IP checksum offload and in the application itself check for such 
capability and display a
warning in case it is not supported.

Sergio
diff mbox

Patch

diff --git a/examples/ipsec-secgw/ipip.h b/examples/ipsec-secgw/ipip.h
index 322076c..0f7b60f 100644
--- a/examples/ipsec-secgw/ipip.h
+++ b/examples/ipsec-secgw/ipip.h
@@ -41,6 +41,24 @@ 
#include <rte_mbuf.h>

#define IPV6_VERSION (6)
+static inline uint16_t
+ip_sum(const unaligned_uint16_t *hdr, int hdr_len)
+{
+       uint32_t sum = 0;
+
+       while (hdr_len > 1)
+       {
+               sum += *hdr++;
+               if (sum & 0x80000000)
+                       sum = (sum & 0xFFFF) + (sum >> 16);
+               hdr_len -= 2;
+       }
+
+       while (sum >> 16)
+               sum = (sum & 0xFFFF) + (sum >> 16);
+
+       return ~sum;
+}

static inline  struct ip *
ip4ip_outbound(struct rte_mbuf *m, uint32_t offset, uint32_t src, uint32_t dst)
@@ -71,7 +89,8 @@  ip4ip_outbound(struct rte_mbuf *m, uint32_t offset, uint32_t src, uint32_t dst)

        outip->ip_src.s_addr = src;
        outip->ip_dst.s_addr = dst;
-
+       outip->ip_sum = 0;
+       outip->ip_sum = ip_sum((const unaligned_uint16_t *)outip, sizeof(struct ip));
        return outip;
}