aboutsummaryrefslogtreecommitdiffstats
path: root/src/plugins/vmxnet3/input.c
AgeCommit message (Collapse)AuthorFilesLines
2018-11-07vmxnet3: reduce calling vmxnet3_reg_write_inlineSteven1-2/+3
In output.c, we buffer the descriptors and call vmxnet3_reg_write_inline once outside the loop. This change improves the performance dramatically. When refilling the ring, there is no need to inform the device unless explicitly specified by the device (ctrl.update_prod == 1) Change-Id: I7031d58bff0d249e913d14236d416c91eb6ab94a Signed-off-by: Steven <sluong@cisco.com>
2018-10-10vmxnet3: better error handlingSteven1-11/+26
try harder on output - if there is no descriptor space available, try to free up some and check again. make sure we free the buffer if error is encoutered on input. Change-Id: I41a45213e29de71935afe707889e515037cd081f Signed-off-by: Steven <sluong@cisco.com>
2018-10-03vmxnet3: coverity woeSteven1-3/+6
Coverity complains that hb might be null when !prev_b0 is true. It may be right, but not likely. To make the code more explicit when it parses a complete packet, set got_packet = 1 and test got_packet instead of prev_b0 which is somewhat obscure. Use vlib_buffer_free_one rather than vlib_buffer_free_no_next in output.c which takes care of chain buffers. Change-Id: I6e0587605fdc622c3f55fedd74c474666631ed91 Signed-off-by: Steven <sluong@cisco.com>
2018-10-03vmxnet3: error handlingSteven1-19/+41
outbound -- if we have to drop the packet due to no descriptor space is available, drop the whole packet, not fragments. inbound -- check and drop error packets Change-Id: Ida1d32e61521bafd67f714d729ad53cd7c487dc6 Signed-off-by: Steven <sluong@cisco.com>
2018-09-25vmxnet3: guard against array overflowSteven1-2/+3
Under extreme condition, it is possible for input node to have more than 256 packets available to process. Add a check to the while loop to prevent overrun buffer_indices and nexts. Change-Id: Id9830e5c254f04216eb79e864a5460e08cf2e4e5 Signed-off-by: Steven <sluong@cisco.com>
2018-09-20vmxnet3: invoke vlib_buffer_enqueue_to_next() with the wrong buffers for ↵Steven1-7/+8
chain buffers If we invoke the subject API with 2 buffers, each with 2 chains, the content of buffers[0] should be head of 1st buffer, and content of buffer[1] should be head of 2nd buffer. What the code did was to put buffers[0] = head of 1st buffer buffers[1] = next chain of 1st buffer buffers[2] = head of 2nd buffer buffers[3] = next chain of 2nd buffer This is wrong and can cause crash. The fix is to only increment bi when the entire packet is found which may consist of multiple fragments. Change-Id: If02cd5186a039d7a6c08a0959112840bdb242317 Signed-off-by: Steven <sluong@cisco.com>
2018-09-18vmxnet3: add support for "non-default" next nodeSteven1-2/+53
Support feature arc Support set interface next node Enqueue packet to either ip4, ip6, or ethernet_input based on packet type Change-Id: I11fb6bba98ee0bfa1d057474fc6cf3be48ef1c48 Signed-off-by: Steven <sluong@cisco.com>
2018-09-14vmxnet3 device driverSteven Luong1-0/+295
Implemented vmxnet3 deivice driver for VMWare ESXi. Tested with Ubuntu 18.04 connected to ESXi 6.0 Ubuntu-18.04 (VPP) --- ESXi-6.0 Change-Id: I85fbc86f2d8532b017bc4271612d17e24e498e4d Signed-off-by: Steven Luong <sluong@cisco.com>