Hi Ajit, I'm using firmware version 219.0.144.0.of
I'm not sure that the problem is about the capability of the firmware. By digging the source code of bnxt PMD, it seems that this problem is related to bnxt_validate_and_parse_flow_type() function which throws an error if the destination Ethernet address is broadcast Ethernet address. I'm using the following URL as reference. https://github.com/DPDK/dpdk/blob/v21.11/drivers/net/bnxt/bnxt_flow.c#L228 >From what I can understand of David statement, it should not throw an RTE error but just leave an incompatible flow non-offloaded. Best regards. On Thu, Feb 9, 2023 at 12:14 AM Ajit Khaparde <ajit.khapa...@broadcom.com> wrote: > Hi, > From what I can see, it looks like the offload is being attempted on a > card which does not have offload functionality enabled. > Can you share the FW version on the NICs? > > If needed, will it be possible for you to update the firmware on the NICs? > > For the warning regarding flow control setting, let me check and get back. > > Thanks > Ajit > > On Wed, Feb 8, 2023 at 4:14 AM Lazuardi Nasution <mrxlazuar...@gmail.com> > wrote: > > > > Hi Ajit, > > > > Have you find the way to overcome this problem? Would you mind to > explain why this reserved Ethernet addresses throw error on offloading the > flows and not just make related flows non-offloaded? > > > > Another think, but not so important is bnxt PMD logs warning about > cannot do flow control on VF even though I have used none, true or false of > interface flow control setting. This warning always appear on OVS > restarting. > > > > Best regards. > > > > On Tue, Feb 7, 2023, 12:21 AM Lazuardi Nasution <mrxlazuar...@gmail.com> > wrote: > >> > >> Hi Ajit, > >> > >> I'm using the following versions. > >> > >> dpdk_version : "DPDK 21.11.2" > >> ovs_version : "3.0.1" > >> > >> Best regards. > >> > >> On Tue, Feb 7, 2023 at 12:12 AM Ajit Khaparde < > ajit.khapa...@broadcom.com> wrote: > >>> > >>> On Mon, Feb 6, 2023 at 9:02 AM Lazuardi Nasution < > mrxlazuar...@gmail.com> wrote: > >>> > > >>> > Hi David, > >>> > > >>> > I think I can understand your opinion. So your target is to prevent > frames with those ethernet addresses from reaching CP, right? FYI, I'm > using bonded VFs of bonded PFs as OVS-DPDK interfaces, so offcourse LACP > should be handled by bonded PFs only. > >>> What is the version of DPDK & OVS used here, BTW? Thanks > >>> > >>> > > >>> > Best regards, > >>> > > >>> > On Mon, Feb 6, 2023 at 11:54 PM David Marchand < > david.march...@redhat.com> wrote: > >>> >> > >>> >> On Mon, Feb 6, 2023 at 5:46 PM Lazuardi Nasution < > mrxlazuar...@gmail.com> wrote: > >>> >> > > >>> >> > HI David, > >>> >> > > >>> >> > Don't you think that offload of reserved Ethernet address should > be disabled by default? > >>> >> > >>> >> What OVN requests in this trace (dropping) makes sense to me if > those > >>> >> lacp frames are to be ignored at the CP level. > >>> >> I don't see why some ethernet address would require some special > >>> >> offloading considerations, but maybe others have a better opinion on > >>> >> this topic. > >>> >> > >>> >> > >>> >> -- > >>> >> David Marchand > >>> >> >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
