[dpdk-dev] ixgbe: fix compile error with gcc4.4 (used RHEL 6)

Tested-by: Haifeng Tang<haifengx.tang@intel.com>

This patch just  includes one file, and has been tested by Intel.
Please see the detail information from the attachment.


-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
Sent: Thursday, September 18, 2014 6:56 PM
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH] ixgbe: fix compile error with gcc4.4 (used RHEL 6)

The refcnt field is contained within an anonymous union within the mbuf data structure, and gcc 4.4 gives an error about an unknown field unless the initialiser for the field is contained within extra braces.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
1.9.3
  

2014-09-25 02:13, Tang, HaifengX:
> Tested-by: Haifeng Tang<haifengx.tang@intel.com>
> 
> This patch just  includes one file, and has been tested by Intel.
> Please see the detail information from the attachment.

Attachment is filtered out. Please do not try to attach some files for
the mailing list.

By the way, this patch has already been integrated. So this test report
is not really useful anymore.
  

Hi Thomas,

 I will work with team to see if we can improve test report.
 Because intel validation team will continue to upgrade test cases to verify feature,
 I think that it's still worth to verify patch or features even it has already integrated branch.

 Thanks
Waterman 

>-----Original Message-----
>From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
>Sent: Thursday, September 25, 2014 3:02 PM
>To: Tang, HaifengX
>Cc: dev@dpdk.org
>Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix compile error with gcc4.4 (used RHEL 6)
>
>2014-09-25 02:13, Tang, HaifengX:
>> Tested-by: Haifeng Tang<haifengx.tang@intel.com>
>> 
>> This patch just  includes one file, and has been tested by Intel.
>> Please see the detail information from the attachment.
>
>Attachment is filtered out. Please do not try to attach some files for the mailing list.
>
>By the way, this patch has already been integrated. So this test report is not really useful anymore.
>
>--
>Thomas
  

2014-09-25 13:07, Cao, Waterman:
>  I will work with team to see if we can improve test report.
>  Because intel validation team will continue to upgrade test cases to verify feature,
>  I think that it's still worth to verify patch or features even it has already integrated branch.

Of course, it's important to continue validation after integration.
But please do not send test report on the list for patches which are
already integrated, except for 2 cases:
1) there is an error
2) this is a new feature and you want to explain how to test it
(btw, how do you test "zero copy" and "one copy" for virtio?)

About report content, please add these informations:
- commit id or tag used as a base to apply the patch
- tools used for the test (testpmd, sample, qemu, etc)
- command parameters if relevant
- test topology if relevant

If someone think about an useful information I missed, please share it.

We could write some guidelines for test and bug reports and publish it
on the website. Drafts are welcome.

Thanks
  

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, September 25, 2014 4:05 PM
> To: Cao, Waterman
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] patches validation
> 
> 2014-09-25 13:07, Cao, Waterman:
> >  I will work with team to see if we can improve test report.
> >  Because intel validation team will continue to upgrade test cases to verify feature,
> >  I think that it's still worth to verify patch or features even it has already integrated branch.
> 
> Of course, it's important to continue validation after integration.
> But please do not send test report on the list for patches which are
> already integrated, except for 2 cases:
> 1) there is an error
> 2) this is a new feature and you want to explain how to test it
> (btw, how do you test "zero copy" and "one copy" for virtio?)
> 
> About report content, please add these informations:
> - commit id or tag used as a base to apply the patch
> - tools used for the test (testpmd, sample, qemu, etc)
> - command parameters if relevant
> - test topology if relevant
> 
> If someone think about an useful information I missed, please share it.

May be it is just me, but what's wrong with mail for every tested patch?
At least it makes easy to check was the patch formally validated or not - all you have to do - grep through mail archives.
Konstantin

> We could write some guidelines for test and bug reports and publish it
> on the website. Drafts are welcome.
> 
> Thanks
> --
> Thomas
  

2014-09-25 23:29, Ananyev, Konstantin:
> From: Thomas Monjalon
> > 2014-09-25 13:07, Cao, Waterman:
> > >  I will work with team to see if we can improve test report.
> > >  Because intel validation team will continue to upgrade test cases to verify feature,
> > >  I think that it's still worth to verify patch or features even it has already integrated branch.
> > 
> > Of course, it's important to continue validation after integration.
> > But please do not send test report on the list for patches which are
> > already integrated, except for 2 cases:
> > 1) there is an error
> > 2) this is a new feature and you want to explain how to test it
> > (btw, how do you test "zero copy" and "one copy" for virtio?)
> > 
> > About report content, please add these informations:
> > - commit id or tag used as a base to apply the patch
> > - tools used for the test (testpmd, sample, qemu, etc)
> > - command parameters if relevant
> > - test topology if relevant
> > 
> > If someone think about an useful information I missed, please share it.
> 
> May be it is just me, but what's wrong with mail for every tested patch?
> At least it makes easy to check was the patch formally validated or not
> - all you have to do - grep through mail archives.

The right place to check something about a patch is the git history.
So it's important to send test reports before having it integrated in git.
Doing so, without any reference to commit id, imply that the patch is pending.
If you think it's really important to send test report about an integrated
patch, the commit id must be clearly visible to quickly understand its status.
There is something else wrong about these test reports: there is no useful
information about how to reproduce the test.
So it's not forbidden to send any email you want but please try to be more
informative and easy to understand. We are getting a huge email traffic so
everyone must be concerned about how to make it effective.

Thanks