> Hi Chaoyong,
>
> some comments as below.
>
>
> 在 2023/10/8 9:50, Chaoyong He 写道:
> > From: Long Wu <long...@corigine.com>
> >
> > Bonding PMD does not let member ports know the bonding port's
> > information, like how many member ports the bonding port has, what
> > mode the bonding port is in and so on.
> >
> > Add the notification interface for bonding port to let member port
> > know it is added to a bonding port and what the bonding port's
> > configuration is. If so the member ports have chance to achieve its
> > bond-flow-offlod or other private bonding functions.
> "its bond-flow-offlod or other private bonding functions"
> I wonder that what PMDs can do with this.
> Can you give an example in PMD to help others review?
After this patch series, I will send out nfp PMD code about "its
bond-flow-offlod or other private bonding functions ".
I can explain here:
"bond-flow" means the flow rule's destination port is a bonding port.
Now DPDK can use bonding port as the source port in a flow rule and member
ports can offload this flow.
But member ports cannot offload a flow that its destination port is a bonding
port.
Because the member ports don't know the bonding port. (Of course, some PMDs has
its self-function to let member ports know the bonding port but it doesn't a
general "DPDK" way).
After this "notify patch", DPDK can do "bond-flow-offload", also "other private
bonding functions"(like hardware balance policy, primary port changing and so
on) can work.
> >
> > Signed-off-by: Long Wu <long...@corigine.com>
> > Reviewed-by: James Hershaw <james.hers...@corigine.com>
> > Reviewed-by: Chaoyong He <chaoyong...@corigine.com>
> > ---
> > drivers/net/bonding/eth_bond_private.h | 1 +
> > drivers/net/bonding/rte_eth_bond.h | 46 ++++++++++++++++
> > drivers/net/bonding/rte_eth_bond_api.c | 73
> ++++++++++++++++++++++++++
> > drivers/net/bonding/rte_eth_bond_pmd.c | 27 ++++++++--
> > drivers/net/bonding/version.map | 3 ++
> > lib/ethdev/ethdev_driver.h | 18 +++++++
> > 6 files changed, 165 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/bonding/eth_bond_private.h
> > b/drivers/net/bonding/eth_bond_private.h
> > index e688894210..f69e85c199 100644
> > --- a/drivers/net/bonding/eth_bond_private.h
> > +++ b/drivers/net/bonding/eth_bond_private.h
> > @@ -180,6 +180,7 @@ struct bond_dev_private {
> > uint8_t member_update_idx;
> >
> > bool kvargs_processing_is_done;
> > + bool notify_member; /**< Enable member notification of bonding port.
> > +*/
> >
> > uint32_t candidate_max_rx_pktlen;
> > uint32_t max_rx_pktlen;
> > diff --git a/drivers/net/bonding/rte_eth_bond.h
> > b/drivers/net/bonding/rte_eth_bond.h
> > index f10165f2c6..737beca446 100644
> > --- a/drivers/net/bonding/rte_eth_bond.h
> > +++ b/drivers/net/bonding/rte_eth_bond.h
> > @@ -351,6 +351,52 @@ rte_eth_bond_link_up_prop_delay_set(uint16_t
> bonding_port_id,
> > int
> > rte_eth_bond_link_up_prop_delay_get(uint16_t bonding_port_id);
> >
> > +/**
> > + * Set the flag of whether bonding port notifies member ports.
> > + *
> > + * @param bonding_port_id
> > + * Port ID of bonding device.
> > + * @param notify_member
> > + * Flag of whether bonding port notifies member ports.
> > + *
> > + * @return
> > + * 0 on success, negative value otherwise.
> > + */
> > +__rte_experimental
> > +int
> > +rte_eth_bond_notify_member_flag_set(uint16_t bonding_port_id, bool
> > +notify_member);
> s/notify_membe/notify in input?
> because function name reveals the meaning already.
Thank you, you are right.
> > +
> > +/**
> > + * Get the flag of whether bonding port notifies member ports.
> > + *
> > + * @param bonding_port_id
> > + * Port ID of bonding device.
> > + * @param notify_member
> > + * Flag of whether bonding port notifies member ports.
> > + *
> > + * @return
> > + * 0 on success, negative value otherwise.
> > + */
> > +__rte_experimental
> > +int
> > +rte_eth_bond_notify_member_flag_get(uint16_t bonding_port_id, bool
> > +*notify_member);
> > +
> > +/**
> > + * Notify the member ports of bonding port's information.
> > + *
> > + * This interface is called in the following functions:
> > + * - bond_ethdev_lsc_event_callback()
> > + * - bond_ethdev_configure()
> Is this interface used just in these cases?
> If so I don't think it should be a API in eth_dev_op.
Sorry I'm a bit confused.
Do you mean "rte_eth_bond_notify_members" this interface? This interface is
called in 3 functions.
> > ...
> > + struct rte_eth_dev *member_dev[RTE_MAX_ETHPORTS];
> > +
> > + if (valid_bonding_port_id(bonding_port_id) != 0)
> > + return -EINVAL;
> > +
> > + bond_dev = &rte_eth_devices[bonding_port_id];
> > + internals = bond_dev->data->dev_private;
> > +
> > + for (i = 0; i < internals->member_count; i++) {
> > + member_port_id = internals->members[i].port_id;
> > + member_dev[i] = &rte_eth_devices[member_port_id];
> > + if (*member_dev[i]->dev_ops->bond_notify_member == NULL)
> > + return -ENOTSUP;
> > + }
> Do we need all member ports support bond_notify_member api?
> If allow user to select one member port to notify? This might be more general.
> In addition, this action here is inconsistent with above handle(do not
> notify member if doesn't supportbond_notify_member API).
Yes, we do not need all member ports support this API.
I just want to have a stricter restriction on this feature before, but I think
your suggestion is better.
> > ...
