> -----Original Message-----
> From: Shahaf Shuler [mailto:shah...@mellanox.com]
> Sent: Tuesday, December 12, 2017 6:31 AM
> To: Ananyev, Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org; 
> Nicolau, Radu <radu.nico...@intel.com>
> Subject: RE: [dpdk-dev] [PATCH 14/39] examples/ip_reassembly: convert to new 
> ethdev offloads API
> 
> Monday, December 11, 2017 5:04 PM, Ananyev, Konstantin:
> > > +         if ((dev_info.tx_offload_capa & port_conf.txmode.offloads)
> > !=
> > > +             port_conf.txmode.offloads) {
> > > +                 printf("Some Tx offloads are not supported "
> > > +                        "by port %d: requested 0x%lx supported
> > 0x%lx\n",
> > > +                        portid, port_conf.txmode.offloads,
> > > +                        dev_info.tx_offload_capa);
> > > +                 port_conf.txmode.offloads &=
> > dev_info.tx_offload_capa;
> > > +         }
> >
> > Sort of generic question regarding most examples - wouldn't it be better to
> > do rte_exit() if device doesn't support the offloads we expect instead of
> > masking off unsupported offloads and continue?
> > Konstantin
> 
> We already started to discuss this question, see [1].
> 
> I agree that it is wrong approach to mask the not supported offloads and 
> continue the application.
> So now I we have 2 options:
> 1. report the warning and let the PMD to fail the device configuration.
> 2. like you suggested, report the error and exit the application.
> 
> While it is wrong for application to set offloads which are not reported by 
> the device capabilities, the input I got from Radu is that there are
> a lot of PMDs that will break with option 2, see [1].
> One example is ixgbe which expects to have CRC offload enabled with IPSEC but 
> don't report it on its caps.
> 
> So my current direction is to make the examples less strict, and give the 
> option for the PMD to fail those if not supported.
> Any objection?

So basically option #1 from the above?
If so, none from me.

> 
> [1] http://dpdk.org/ml/archives/dev/2017-December/083441.html
> 

Reply via email to