From: Shahaf Shuler <shahafs@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Yongseok Koh <yskoh@mellanox.com>
Subject: Re: [dpdk-dev] Critical fixes for next-net-mlx
Date: Thu, 24 May 2018 18:55:59 +0000 [thread overview]
Message-ID: <DB7PR05MB4426AC9338D399D90CA72765C36A0@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <302b6f86-b1bb-663e-b03a-92ae370d6480@intel.com>
Thursday, May 24, 2018 7:56 PM, Ferruh Yigit:
> Subject: Re: Critical fixes for next-net-mlx
>
> On 5/24/2018 3:11 PM, Shahaf Shuler wrote:
> > Hi Ferruh,
> >
> > In next-net-mlx and for “next-net” there are several critical fixes:
> > * fecb5cb net/mlx4: drop support in Mellanox OFED 4.2 Small doc update
> > to notify all users – this is for next-net.
>
> Documentation patches are accepted for rc6, ok for this one.
Thanks.
>
> > * 995b985 net/mlx5: fix generic tunnel offloading compatibility check
> > w/o it we cannot compile on RH7.5 with inbox libs (rdma-core).
>
> This is updating Makefile, changing the data structure to check to give a
> configuration decision. What to check has been updated because of what is
> available in a distro.
>
> I believe this is not something to break the build, and should be safe for rest
> of the dpdk.
>
> But from your point of view, if this data structure cause any un-expected
> result in any other distro, you won't have another opportunity to fix, I just
> want to confirm are you sure about change?
Confirm.
In fact with this change the check is more strict.
The check that was before checked for enum. But with backport of patches to the distro rmda-core tree, the enum can be defined even though not all configuration struct exists.
For example,
enum {
X=1,
Y=2,
Z=3,
};
Y can be defined when one backport the patch that introduce Z.
The configuration struct however exists only if the needed feature is fully backported (enum + struct).
This is way this change is safe.
>
> > * 8276073 net/mlx5: fix SW parser
> > offset w/o it TSO for tunnel is broken
>
> What is the scope of this one?
This is to fix the offloads introduced by commits:
5f8ba81 net/mlx5: support generic tunnel offloading
5355f44 ethdev: introduce generic IP/UDP tunnel checksum and TSO
i.e. the support for generic IP/UDP tunnel Tx offloads.
Commit log doesn't have enough information.
> What feature is broken, what is the exposure is it broken for all use cases or
> for some, is there any workaround?
Unfortunately no.
As you can see from the commit the inner/UDP offset is passed incorrectly to the device, causing TSO and checksum offload not to work (as the device access the wrong offset in the packet headers).
Without this patch the feature is broken.
>
> >
> > Hope it will be possible to include those.
> >
> > --Shahaf
next prev parent reply other threads:[~2018-05-24 18:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-24 14:11 Shahaf Shuler
2018-05-24 16:56 ` Ferruh Yigit
2018-05-24 18:55 ` Shahaf Shuler [this message]
2018-05-25 8:45 ` Ferruh Yigit
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=DB7PR05MB4426AC9338D399D90CA72765C36A0@DB7PR05MB4426.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=yskoh@mellanox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).