> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, November 26, 2014 1:31 PM > To: Jastrzebski, MichalX K > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 2/2] testpmd: add mode 4 support v6 > > 2014-11-26 11:17, Michal Jastrzebski: > > From: Pawel Wodkowski <pawelx.wodkowski at intel.com> > > --- a/app/test-pmd/csumonly.c > > +++ b/app/test-pmd/csumonly.c > > @@ -254,8 +254,17 @@ pkt_burst_checksum_forward(struct fwd_stream *fs) > > */ > > nb_rx = rte_eth_rx_burst(fs->rx_port, fs->rx_queue, pkts_burst, > > nb_pkt_per_burst); > > +#ifndef RTE_LIBRTE_PMD_BOND > > if (unlikely(nb_rx == 0)) > > return; > > +#else > > + if (unlikely(nb_rx == 0 && (fs->forward_timeout == 0 || > > + fs->next_forward_time > rte_rdtsc()))) > > + return; > > + > > + if (fs->forward_timeout != 0) > > + fs->next_forward_time = rte_rdtsc() + fs->forward_timeout; > > +#endif > > I don't understand why you need to make such change for bonding, > and there is no comment to explain. > Bonding should be a PMD like any other and shouldn't require such change. > I don't know mode 4 but it seems there is a design problem here. >
It is an implication of requirement that was formed on beginning of bonding implementation - bonded interface should be transparent to user app. But this requirement in is in collision with mode 4. It need to periodically receive and transmit frames (LACP and marker) that are not passed to user app but processed/produced in background. If this will not happen in at least 10 times per second mode 4 will not work. Most of (all?) user applications do RX/TX more often than 10 times per second, so this will have neglectable impact to those apps (it will have to check this 100ms maximum interval of rx/tx as I did in code you pointed). We had discussed all options with Declan and Bruce, and this seems to be the most transparent way to implement mode 4 without using any kind of locking inside library. Pawe?
