On Mon, Jan 13, 2020 at 10:54 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Mon, Jan 13, 2020 at 04:42:10PM +0000, Chris Mason wrote: > > Btrfs basically does this now, honestly iomap isn't that far away. > > Given how sensible iomap is for this, I'd rather see us pile into > > that abstraction than try to pass pagevecs for large ranges. > > Otherwise, if > > I completely misread this at first and thought you were proposing we > pass a bio_vec to ->readahead. Initially, this is a layering > violation, completely unnecessary to have all these extra offset/size > fields being allocated and passed around. But ... the bio_vec and the > skb_frag_t are now the same data structure, so both block and network > use it. It may make sense to have this as the common data structure > for 'unit of IO'. The bio supports having the bi_vec allocated > externally to the data structure while the skbuff would need to copy > the array. > > Maybe we need a more neutral name than bio_vec so as to not upset > people. page_frag, perhaps [1]. > > [1] Yes, I know about the one in include/linux/mm_types_task.h Note that bio_vecs support page merging, so page fragment isn't very descriptive. Not sure what a good name would be, but fragment isn't it. But any shared type would imply that others should support that as well if you're passing it around (or by pointer). -- Jens Axboe
