On 05/15/2014 06:05 PM, Thomas Graf wrote: > On 05/15/2014 03:09 PM, Andrey Korolyov wrote: >>>> resulting patch can be created without wasting much effort away. >>> >>> Unfortunately Zoltan's fix affecting skb_zerocopy() was merged after el7 >>> code freeze so 7.0 will export that as void but you'll need a workaround >>> anyway as upstream kernels have been released for both signatures. >>> >>> A subsequent update is very likely to incorporate the fix which will >>> change the return value to int. >> >> Thomas, can you give an insight on approximate timeframe for next update >> release? Will it be 7.0 branch or 7.1? Looks like that the kernel can be >> updated in some weeks, according to previous dates of releases, but I`d >> prefer to ask anyway. > > It will be both. 7.0 is yet to go GA but we the fix can be nominated > for a 7.0.z async release. The prereq for that is inclusion of the fix > in 7.1. > Ok, thanks.
>> I`ll just rip out all gre/vxlan/lisp-related code >> in a meantime for tests, but it will be lovely to allow possibility to >> use more or less generic OVS datapath distribution. > > Without knowing your exact requirement to use the external kmod, the > easiest way towards that would be to continue submitting & merging all > code to kernel.org and not depend on an externally built kmod. Generally speaking, I am not bounded by fixed kABI provided by RedHat, but want to stay on permanent one instead of doing feature hunting with lot kernel upgrades in a year-long span or so, so unmodified or barely modified RH sources giving a perfect chance to do this. Choice for using external kmod for OVS is motivated mainly by a lag between master and RH versions (I am OpenFlow user and very hungry for new protocol extensions and features, like tables in 2.2). Stable kernels maintained by gregkh lacking new features, like development of dm-cache and kvm enhancements, so my choice, though it may looks not smart, gives me stable kABI (and potential to upgrade a lot of functionality without reboot or waiting for maturity of kpatch-like tools) and, in other hand, more or less stable source of new features and improvements, despite just functionality fixes and security backports. I am avoiding any alterations of the provided source because related bugreports will be useless for everyone, that`s why I have to stay and wait for release. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
