Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: >> Eelco Chaudron wrote: >> > >> > >> > On 23 Jun 2021, at 1:37, John Fastabend wrote: >> > >> > > Lorenzo Bianconi wrote: >> > >> From: Eelco Chaudron <echaudro@xxxxxxxxxx> >> > >> >> > >> This change adds support for tail growing and shrinking for XDP multi-buff. >> > >> >> > > >> > > It would be nice if the commit message gave us some details on how the >> > > growing/shrinking works in the multi-buff support. > [...] >> > Guess this is the tricky part, applications need to be multi-buffer aware. If current applications rely on bpf_xdp_adjust_tail(+) to determine maximum frame length this approach might not work. In this case, we might need an additional helper to do tail expansion with multi buffer support. >> > >> > But then the question arrives how would mb unaware application behave in general when an mb packet is supplied?? It would definitely not determine the correct packet length. >> >> Right that was my conclusion as well. Existing programs might >> have subtle side effects if they start running on multibuffer >> drivers as is. I don't have any good ideas though on how >> to handle this. > > what about checking the program capabilities at load time (e.g. with a > special program type) and disable mb feature if the bpf program is not > mb-aware? (e.g. forbid to set the MTU greater than 1500B in xdp mode). So what happens when that legacy program runs on a veth and gets an mb-enabled frame redirected into it? :) -Toke
