summaryrefslogtreecommitdiffstats
path: root/src/vlibmemory
diff options
context:
space:
mode:
authorSteven Luong <sluong@cisco.com>2019-10-02 07:33:48 -0700
committerDamjan Marion <dmarion@me.com>2019-10-07 20:02:17 +0000
commit4442f7cb2ebca129170a559d846712c2b65d5051 (patch)
tree0c1fa7b628e3e7e1b1ab774fb69e0d8b359ab3d9 /src/vlibmemory
parent0dd97d473bc0c958d9fcea508e1f5122a137b23f (diff)
devices: vhost not reading packets from vring
In a rare event, after the vhost protocol message exchange has finished and the interface had been brought up successfully, the driver MAY still change its mind about the memory regions by sending new memory maps via SET_MEM_TABLE. Upon processing SET_MEM_TABLE, VPP invalidates the old memory regions and the descriptor tables. But it does not re-compute the new descriptor tables based on the new memory maps. Since VPP does not have the descriptor tables, it does not read the packets from the vring. In the normal working case, after SET_MEM_TABLE, the driver follows up with SET_VRING_ADDRESS which VPP computes the descriptor tables. The fix is to stash away the descriptor table addresses from SET_VRING_ADDRESS. Re-compute the new descriptor tables when processing SET_MEM_TABLE if descriptor table addresses are known. Type: fix Ticket: VPP-1784 Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: I3361f14c3a0372b8d07943eb6aa4b3a3f10708f9 (cherry picked from commit 61b8ba69f7a9540ed00576504528ce439f0286f5)
Diffstat (limited to 'src/vlibmemory')
0 files changed, 0 insertions, 0 deletions