Bug 1733402
Summary: | i40e nic: spoofchk off does not take effect when vf add to ovs bridge | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | liting <tli> | |
Component: | openvswitch2.11 | Assignee: | Eelco Chaudron <echaudro> | |
Status: | CLOSED ERRATA | QA Contact: | qding | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | FDP 19.C | CC: | ctrautma, fhallal, jhsiao, kfida, qding, ralongi, tredaelli | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | openvswitch2.11-2.11.0-36.el7fdn | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1796586 (view as bug list) | Environment: | ||
Last Closed: | 2020-03-10 09:35:30 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: |
Description
liting
2019-07-26 02:32:58 UTC
This looks like a duplicate to me for https://bugzilla.redhat.com/show_bug.cgi?id=1719644, can you verify if you get any of the odd DPDK messages like this: https://mails.dpdk.org/archives/dev/2019-June/135593.html (In reply to Eelco Chaudron from comment #1) > This looks like a duplicate to me for > https://bugzilla.redhat.com/show_bug.cgi?id=1719644, can you verify if you > get any of the odd DPDK messages like this: > https://mails.dpdk.org/archives/dev/2019-June/135593.html No, it is not duplicate with bug1719644. After restart openvswitch service, ping still failed when spoofchk is off(vf mac different with guest's eth0 mac). There is no the dpdk messages like following log. The same issue also exist on ixgbe nic. 2019-06-24T15:16:55.052Z|00001|dpdk|ERR|i40evf_handle_aq_msg(): Request 0 is not supported yet thanks, Li Ting When experimenting with a fix for BZ1719644 I was able to replicate the issue and confirm it's not solved by the fix fixing BZ1719644. I've asked Intel for any hints to why disabling spoofchk and changing the MAC to a different mac is still not passing traffic. Odd is that even after restarting OVS the issue persists. Making me think this is kernel driver related and not DPDK. Did some more research and the spoof check works as designed, however, it's for packet ingressing into the VF from the host. In the reverse direction packets, no matching the configured MAC are dropped. To also enable those packets to pass you have to enable trust mode, i.e. "ip link set dev eth0 vf 1 trust on". Having said this (and tested) this still does not work on the fly, once you enable trusted mode you still need to restart OVS. I can see with the patch for BZ1719644 the reset function is called, but it does not have the desired effect. I'll do further research, and touch base with Intel. Sent fix to DPDK mailing list as it's an internal state issue: http://mails.dpdk.org/archives/dev/2019-September/143683.html With this patch and the patch for BZ1719644 this will fix the problem. (In reply to Eelco Chaudron from comment #5) > Sent fix to DPDK mailing list as it's an internal state issue: > > http://mails.dpdk.org/archives/dev/2019-September/143683.html Still, some discussion is going on around this patch... Sent v2 patch: http://mails.dpdk.org/archives/dev/2019-November/151687.html Patch backported to OVs 2.12 and 2.13 FDN. Images are available here: http://download-node-02.eng.bos.redhat.com/brewroot/packages/openvswitch2.11/2.11.0/36.el7fdn/ http://download-node-02.eng.bos.redhat.com/brewroot/packages/openvswitch2.12/2.12.0/14.el7fdn/ Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0743 |