On 8/7/21 10:25 PM, Alexander Bulekov wrote:
> On 210807 1019, Philippe Mathieu-Daudé wrote:
>> On 8/7/21 12:23 AM, Alexander Bulekov wrote:
>>> Encapsulation offload (offload mode 1) is a valid mode present in the
>>> kernel that isn't implemented in QEMU, yet.
>>>
>>> https://lore.kernel.org/lkml/20200528015426.8285-4-dos...@vmware.com/
>>>
>>> Add a stub for this mode, to avoid the guest-triggerable assertion.
>>>
>>> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/517
>>> Signed-off-by: Alexander Bulekov <alx...@bu.edu>
>>> ---
>>>  hw/net/vmxnet3.c | 5 +++++
>>>  hw/net/vmxnet3.h | 1 +
>>>  2 files changed, 6 insertions(+)
>>>
>>> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
>>> index 41f796a247..62e11d0e3e 100644
>>> --- a/hw/net/vmxnet3.c
>>> +++ b/hw/net/vmxnet3.c
>>> @@ -443,6 +443,11 @@ vmxnet3_setup_tx_offloads(VMXNET3State *s)
>>>          net_tx_pkt_build_vheader(s->tx_pkt, false, false, 0);
>>>          break;
>>>  
>>> +    case VMXNET3_OM_ENCAP:
>>> +        VMW_PKPRN("Encapsulation offload requested, but not available\n");
>>> +        return false;
>>> +        break;
>>
>> No need to break if you returned (unreachable).
> 
> I included it in case the feature ends up being added, so there is one
> less thing to worry about, but I can remove it. There are a couple of
> places in QEMU where this occurs, so I wasn't sure about the best
> practice.

I don't know if there is an official "best practice". My style /
recommendation is to try to use single exit point when possible
so I can easily add trace events.


Reply via email to